Home

Node.js: The Isomorphic Holy Grail

Published 12/27/2017

JavaScript has chased the isomorphic development promise since nearly the beginning.

Remember from our history lesson, before JavaScript was even called JavaScript, Netscape was pursuing LiveWire to over JavaScript on the server side.

Spoilers: It didn’t quite work out for them.

In fact, LiveWire (the JavaScript framework) doesn’t even have a Wikipedia entry today.

And in the Internet age, if you don’t have a Wikipedia entry, you’re irrelevant.

However, the early framers of JavaScript proved to be prescient; albeit ahead of their time.

So what the heck is isomorphic development anyway?

Basically, it’s being able to use the same coding and language on the server as you use on the client or browser.

OK. That doesn’t sound too impressive. We hear you.

So why all the hype?

To answer that, we need to step back a little bit.

As you remember, to this point, JavaScript has been the programming language of the browser.

It has only lived inside the web pages you visit on your browser or phone.

To use our house analogy again, it’s the stuff that causes a door to open, the phone to ring and the lights to come on.

The other two components were HTML and CSS – and really, they still are.

The CSS represents the look and feel of the house; the interior decorating and the paint, for example.

For the large part, the CSS is static and written in a text editor and deployed “as-is.”

The CSS, generally, changes in response to a user action. Submitting a form with an error may turn green text red, for example.

That’s JavaScript manipulating the CSS.

So if the CSS is the visuals of the house, HTML is the structure.

You may think that the HTML is static like the CSS, and it is, in a lot of respects, but it’s also dynamic.

Let’s stick with the house example.

When the house is getting built, the foundation goes down and doesn’t change at all.

The walls go up and they’re pretty static, too. Same with the roof.

With HTML, there’s a foundation, walls and a roof, too.

These are generally what we call the layout or the shell of a website.

They make up the part of a website that remains consistent from page to page.

Sure, Page A may be a directory of real estate listings and Page B may be an “About Page,” but the surrounding structure of both pages will share a lot of similar elements, just like the house.

A lot of the other elements are built offsite and brought to the house prefabricated.

Doors and windows for example, are generally built somewhere else; by someone else, and brought to the site and installed.

In software development, we call these templates.

Let’s go back to the directory of real estate listings.

These are like window.

But we need something to tell us how many windows to bring to the house.

If we’re displaying a directory of listings, we need to know how many listings to show and what type of listings they are.

This is where the server coding comes into play.

The server, for simplicity’s sake, is just another computer in a remote location.

This server is where the windows come from. The programing language is what tells the server what windows and how many to send, usually by querying a database akin to a complex spreadsheet.

This is all good and well, but it presents a problem for JavaScript because, aside from the brief attempt with LiveWire, it grew up in the browser and was tied directly to it.

The client/browser has a lot of things that the server doesn’t have an vice versa.

JavaScript knew how to turn on the lights in a finished house, but there’s not even any switches to turn on at the window factory.

The JavaScript language just didn’t have the ability to even talk to a database.

This is where Node.js came in.

Node.js provided a framework that added all these features to the JavaScript language and removed the dependency on the browser.

This allowed JavaScript to be run pretty much anywhere.

Now, instead of having to write server instructions in Java, PHP, Ruby, .Net or any of 100 other programming languages and client instructions in JavaScript, you could write both in JavaScript.

This had a number of practical benefits.

First, you no longer needed a developer who was good at more than one language – or two developers who were good at one language.

You just needed a developer who was good with JavaScript.

Second, you could share code between the client and the server.

To use a contrived example, imagine you have to write code to generate a random number between 1 and 10.

With the traditional client and server language separation, you’d need to write the code in JavaScript and then again in whatever other language you were using on the server.

With isomorphic development, you just have to write that code once and you can share it between the server and the client.

So to jump back to the house example, you can have the windows delivered to the house, but you can also have an additional window built on site if needed without needing any other skills than you already have.

This was the promise that LiveWire was seeking to provide nearly 20 years earlier.

It took awhile, but we finally got there around 2008, and it change, not only JavaScript development, but all of software development, forever.