Isomorphic JavaScript Applications — the Future of the Web?

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.


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.


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.


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?


  1. Nope, not buying it.

    Go to a site powered by meteor, for example their own site:

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


    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.

  2. 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. ._.

  3. 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:

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

  5. sg707 says:

    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.

9 more replies