React and the Future of JavaScript

Published 01/03/2018

So if Isomorphic JavaScript was the Holy Grail, that should be the end of the language’s evolution, right?


In fact, another paradigm kind of derailed the early isomorphic achievement.

Just as we had achieved the ability to write a web application using only JavaScript, we decide to roll out a new type of web application – the Single Page Application.

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.

This allows us to keep all the presentation code – HTML, CSS and JavaScript cached and static, meaning we don’t need another language to put it all together for us on the server and send it to the client.

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.

The downside of this new approach was that developers were writing a lot of complex JavaScript that was difficult to manage.

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.

Sure, we can write that part in JavaScript, but we could write that part in pretty much anything else without much difference as well.

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.

So what’s next for JavaScript?

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.

We’ve already written JavaScript to power “Internet of Things” devices such as GPS trackers and health monitoring devices.

JavaScript is used to write video games, too.

There really is no limit to where JavaScript goes next.

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.

Give us a try free for 30 days!

Don't take our word for it. New clients get to try our services free for 30 days.

We'll put together a team of analysts, developers and designers to partner with you and get to work.

To get started, just fill out the form below.

They show a passion for understanding our business objectives

They show a passion for understanding our business objectives

They get the job done on time and are quite adept at using open source technology, which saves us money. Gunner balances pragmatism and perfectionism, which is important to us. After using them for both short term and long term projects, we cannot give a higher recommendation

Sam Petteway - CEO

5348 Vegas Drive
Las Vegas, NV 89108
GSA: GS-35F-306GA | CAGE: 7Q6F5 | DUNS: 078818362
© 2020 Gunner Technology
Privacy Policy | Terms of Use