JavaScript
Article

Isomorphic JavaScript Applications — the Future of the Web?

By Aurelio De Rosa

One of the best known mottos around the web is Java’s Write once, run everywhere. But does this motto apply to Java only? Can we use it to describe JavaScript too? The answer is Yes.

In this article, I’ll introduce you to the concept of isomorphic JavaScript applications, describing what they are and pointing to resources that help you develop this kind of application.

How We Arrived Here

Many years ago, the web was a bunch of static pages made with HTML and CSS without much interactivity. Each user action required the server to create and serve a complete page. Thanks to JavaScript, developers started to create nice effects, but it was with the advent of Ajax that a revolution started. Web developers began to write code that could communicate with the server to send and receive data without the need to reload the page.

As the years have passed, the responsibilities of the client-side code have grown a lot, resulting in a new type of application known as the single-page application (SPA). In an SPA, all the necessary assets are retrieved with a single page load, or dynamically loaded and added to the page as necessary. Some examples of SPAs are Gmail and the StackEdit editor.

SPAs allow for better interactivity, because almost all their operations are executed on the client, keeping communications with the server to a bare minimum. Unfortunately, they also have some major problems. Let’s discuss some of them.

Performance

Because SPAs require more client-side code than static pages, the amount of data to download is increased. This leads to slower initial loading times, which can have drastic consequences – such as frustrated end users and loss of revenue. According to one Microsoft article

A Bing study found that a 10ms increase in page load time costs the site $250K in revenue annually.

SEO

Because single-page applications rely on JavaScript execution, servers don’t produce all the HTML content they used to. Therefore, web crawlers have a lot of difficulties indexing pages. These crawlers are programs that make requests to a web server and analyze the result as raw text, without interpreting and executing the content like a typical browser running JavaScript would do. Recently, Google improved its web crawler so that it can work with JavaScript-based pages, but what about Bing, Yahoo, and all the other search engines? Good indexing is crucial for any business, as it usually leads to more visits and higher revenue.

Isomorphic JavaScript Applications

Isomorphic JavaScript applications are applications written in JavaScript that can run both on the client and on the server. Because of this, you can write the code once and then execute it on the server to render static pages and on the client to allow for fast interactions. So, this approach takes the best of the two worlds and lets you avoid the two issues described before.

Today there are several frameworks that assist you in developing this kind of application. One of them – possibly the most well-known – is Meteor. Meteor is an open-source JavaScript framework, written on top of Node.js, that focuses on real-time web applications. Another project I want to mention is Rendr. It’s a small library developed by Airbnb that allows you to run Backbone.js applications on both the client and the server.

More companies are adopting Node.js for their products. Sharing code between the client and server is becoming a more common and natural choice, and in my opinion is the future of web development. This trend is enhanced by sharing templates through libraries like React.

Conclusion

In this article I’ve introduced you to the concept of isomorphic JavaScript applications, a new approach to developing applications that combines the best of server-side and client-side programming. We’ve also discussed what problems this approach tries to solve, and some projects that you can employ today to embrace this philosophy.

Had you already heard of isomorphic JavaScript applications? Have you developed one? What was your experience?

Comments
Julius_Koronci

Nice article, I am just learning meteor..and it is really awesome..specially the part the it can just run on android and iPhone just with 2-3 commands..althoug I can't really see how it could replace larger applications..maybe in the future smile

MatsSvensson

Nope, not buying it.

Go to a site powered by meteor, for example their own site:
https://www.meteor.com

Disable javascript in the browser, and this is the kind of nifty looking webpages you get:

<body>

</body>

Good luck getting any search-ratings with site full of that stuff!

How is this "the best of the two worlds."?

At least Meteor, seems to be the exact opposite of whats described in the article.
Its like flash-only sites for the new millennium.

thefairystamp

Good luck getting any search-ratings with site full of that stuff!

This is basically the reason why I am still hesitating to use any kind of javascript rendering for actual consumed content. Not everybody uses WordPress by default for anything that is not a webapp. Everybody has been crazy about angular and its competitors for years, making it seem like the only thing produced nowadays is applications. ._.

brothercake

Maybe what we really need is an agnostic language -- you write the code, and the language decides which bits run on the server and which bits run on the client.

In the meantime -- progressive enhancement! Remember that? smile

chrisofarabia

I must admit, I thought the article was rather on the short side - isomorphic apps for a sound bite generation?

sg707

I think you didn't get the real Java's motto

"Write once, test everywhere"

This is just my opinion so please don't be offended. I hope the idea of using front-end and back-end with a single language DO NOT become immensely popular. It is popular but I don't want it to be the standard. Imagine a world where 99.99% of the web application is written using JavaScript. As a developer, we're known to get 'bored' very quickly. I don't want to write only JS for next 30 years of my career. Also, not everyone likes JS. I consider JS as a 'double edged' sword..since there are so many ways to do dumb things compared to other strongly typed languages. I prefer a language that is a 'single edged sword'. It's not as efficient as 'double edged sword' but I just feel safer. By all means, I'm not saying Node.JS is horrible or not but I feel a developer should not be afraid to learn a new programming language and not be stuck on 'Js is the best and this is the only thing I'll ever use' mentality.

Also, the code sharing for front-end and back-end have horrible use cases.
Purpose of

Front-end: Provide UI and provide visualization from back-end data
Back-end: Process business logics that usually deals with integrating with multiple datasources (database for ex.)

There is very little share code in between because they serve different purposes. They commonly use example of 'Form field validations' that is used on JS side and Server side.. Is it that much redundant code to check for field that has a value or not or doing date format check? So at the end, I'm guessing less then 5% of the code is being shared between front-end and back-end. I can be wrong and I like to be proved wrong. Using universal language to share 5% of the code doesn't make any sense to me.

talamaska

there are ways to overcome website crawlers. One of them pre-rendering pages with phantom on the server, and when a robot requests a page, the server returns a static html.
check here for example
http://lawsonry.com/2014/05/diy-angularjs-seo-with-phantomjs-the-easy-way/

oddz

For those here who are complaining about the SEO implication of using Meteor there is a package dedicated to eliminating that disadvantage called spiderable. As for "Isomorphic" applications having spent the last few days reading about Meteor I'm both intrigued and concerned. I'm intrigued by the radical change in philosophy that directly correlates to increase of performance. Though I'm concerned that change is so radical that it will lack adoption simply for the fact that it seems before it's time and premature for building large scale, enterprise level architecture in comparison to tried and true stacks. Many of which offer a more feature rich ecosystem of libraries and tools to achieve specific business goals. Once well known content management systems begin moving to this technology I will be sold but until than I still think that this is to radical to embrace for the masses. Could this type of infrastructure become as popular as LAMP, Rails, etc. perhaps but I wouldn't think anytime soon. Definitely clever and something to watch possibly use for the right project but I would tread carefully given the incompleteness and lack historical success. If this technology is truly evolutionary perhaps it could eliminate or significantly reduce the necessity of caching layers required for many current high traffic, web based software applications. Eliminating the need for caching layers would be impressive and certainly revolutionary for out of the box code. I do find it interesting though that the concept of an isomorphic application using a framework like Meteor breaks the fundamental ideology of separation of concerns and language agnostic service based applications. The code I see looks a lot like the old days of mixing presentation with behavior using embedded and inline behavior. Yet this seems to be the new hotness.

Julius_Koronci

Just reading trough the posts..I saw lots of concern about SEO..but actually this is not the case..you can just simply tell google about your app with meta tags and the fragment attribute and now when a robot visits your site.. meteor recognizes it and you can prerender the html on the server side which can be now perfectly crowled..
I am just planing to put into production my first meteor app and I must say I am kind of impressed..how easy and quick the development is and how many packages are already out there to help you..of course and don't really see it fit for long term projects just yet..but it isn't impossible smile

It is like when someone says that what 10 .net developers can do in 6 months..can 2 php developers do in 1 months..you can just simply add to it can 1 meteor developer do in 2 weeks smile

djsmithme

Client side javascript I get. This, not so much...

Too much trust on the client. Even more things to go wrong client side. Which means even more validating/verifying/lack of trusting on the backend to make sure the data thats getting sent back is correct. I can write it in the same language but I now have to write more.

Julius_Koronci

Not really true..I would say..you have to do the client side stuff anyway its basic UX..to have validation and so on..the thing is that the client side doesn't really change..it is just that it automatically connects with the back-end and it gives you real time like experience..as it does all the things you would usually do with ajax..so if you have built heavy ajax apps you know how complex it can become and how hard it becomes to deal with basic things

AurelioDeRosa

To me this seems that they've done it wrong not that the approach is invalid. I understand that it's insane to advertise a framework of this kind and than have a website that renders nothing when JavaScript is disabled, but I still believe the concept is awesome.

Dev1an

Good luck getting any search-ratings with site full of that stuff!

Did you do a query on Google for "Javascript web framework"? Have a look at the result, I think it's not that bad for a "search-rating" because the first result I get from Google is a site made with Meteor.

Recommended

Learn Coding Online
Learn Web Development

Start learning web development and design for free with SitePoint Premium!

Get the latest in JavaScript, once a week, for free.