In fact, another paradigm kind of derailed the early isomorphic achievement.
You’ll see them referred to as SPAs and the adhere to the “building on site” paradigm we looked at previously.
Essentially, instead of having multiple URLs like you would see on a site like ESPN, NY Times or Fox News, you have a single URL (for those of you screaming about the history object and hash bang URLs, bear with us, we’re trying to keep things simple).
In this model, pages are now more like states. As in, the state of the application is “new” and then clicking a link will change the state of the application to “open” and so forth and so on.
We can keep all this stuff on the client.
Then, this static code can make Ajax requests to a server somewhere to request dynamic data such as a stock price, a user’s session or the score of a game.
After the Ajax request is complete, the static code updates the front end interface to reflect the new data.
Package managers, debuggers and automated testing had been a staple of server side code for the longest time, but nothing really existed for the client.
This gave rise to new tools like Gulp, Grunt, Bower, Webpack and more.
Eventually, entire SPA frameworks began to spring up to solve these issues.
Backbone, Ember, Vue and AngularJS were some of the earlier ones.
This kicked off what we call World Framework War II.
Just as with World Framework War I (which jQuery ultimately won less than five years before), there were pros and cons with all of these frameworks.
Unlike WFW I, WFW II was broken into two “scenes” or acts.
AngularJS won the first act and looked to be in good position to become the next jQuery.
Companies such as Wolfram Alpha, NBC, Walgreens, Intel, Sprint, ABC News and Apple deployed applications with AngularJS.
Google took over development as the official maintainer and the outlook was extremely promising.
It was revolutionary.
But then things got… complicated.
In 2014, the original AngularJS team began working on Angular, a complete rewrite from the same team that built AngularJS.
Let’s drive this point home. Angular was nearly completely different from AngularJS.
Any AngularJS app that wanted to take advantage of the new features and optimizations in Angular needed to be completely rewritten.
This was obviously a pain in the ass, but even more so when you consider that Angular(JS)’s main downside was that it was difficult to learn when compared to the other frameworks.
This inevitably caused backlash from developers, who began looking for a simpler solution.
Fortunately, React was waiting in the wings.
React was much more focused than Angular.
React aimed to do one thing really well – build user interfaces – while leaving the rest to the developer.
In fact, React can be used with Angular.
And like Angular, React, which was developed and maintained by Facebook and Instagram, had support from large companies, including Netflix and Yahoo.
React also used a one-way data flow model which made growing an application easier and less buggy.
Soon after React began its rise, Facebook announced React Native, which was pretty much the same thing except it was used to (natively) develop interfaces for Android and iOS devices rather than the web.
The importance of this cannot be understated.
The advent of React Native removed a huge impediment to small teams, which was being able to affordably build native mobile applications for both the major operating systems while not sacrificing performance or functionality.
Not long after, React overtook Angular and, as of this writing, is the dominate SPA framework.
OK. So what does all that have to do with a step back for isomorphic development?
Well, with all the application logic being built into the client, the server had very little left to do other than some validation and feed creation.
The benefits are still there, but they’re greatly diminished.
But, let’s consider a scenario.
When a user opens an SPA in their web browser, all the client code is there, but the data isn’t.
So the interface needs to do something while the client code fetches the data.
Usually this manifests itself as a loading image or placeholder graphics.
If you want an example, load Facebook on a slow connection.
The client code makes a bunch of Ajax requests and compiles and formats the data and then updates the interface.
That’s not ideal.
That’s where the isomorphic promise comes in.
React can be written on the server as well, so the initial page load of a React app can load, compile and format the data on the server and send it to the client without any loading screens or graphics – all while using the same codebase.
And that’s how we come full circle, again.
The asynchronous nature of the language makes it an ideal choice for a number of types of non-web, non-mobile applications.
And the fact that it is the language of the Internet means the growth into other areas won’t stop anytime soon.
It’s still a really young language and one that has only been taken seriously for less than a decade.
We’re excited for its future and can’t wait to help shape it.