Spoilers: It didn’t quite work out for them.
And in the Internet age, if you don’t have a Wikipedia entry, you’re irrelevant.
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.
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.
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.
The client/browser has a lot of things that the server doesn’t have an vice versa.
This is where Node.js came in.
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.
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 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.