Is Isomorphic JavaScript the Happy Medium You’ve Been Looking For?

There’s an old adage in the Java community: Write once, run anywhere.

It’s meant to illustrate the power of Java, not to be confused with JavaScript, to run the same code on many different devices. As the world of web application development has evolved, however, several technologies have thrown their hats into the ring, perhaps most notably of which is JavaScript.

In the last few years, JavaScript evolved far beyond basic JQuery and, with the introduction of Node, has become a full-featured, back-end development platform. A developer is now able to run JavaScript on both the browser and the server, illustrating a concept more commonly known as Isomorphic JavaScript (JS).

How Did We Get Here?

The rise of the Single Page Application (SPA) introduced a new level of interactivity on the web, meeting demands of people who expect fast, exciting applications. The front-end is fed via an API that can be written in most server-side languages, and the app doesn’t have to make a round-trip to the server to render a new page. Instead, it requests what it needs through asynchronous requests (AJAX) and boom — good to go!

Unfortunately, some problems have arisen with the SPA architecture. Two of the most common are also among the most impactful for users and stakeholders:

    • Performance
        • The user is presented with a loading spinner, or the dreaded “flash of unstyled content” (FOUC) when the site first loads due to data which has not yet been retrieved from the API.
        • The initial load time of the page is slowed due to the full client-side app loading before filling any subsequent requests for data.
    • Search Engine Optimization (SEO)
        • Crawlers cannot effectively render content served up by asynchronous requests, which is problematic for stakeholders on public-facing sites. If a SPA is served almost entirely through AJAX, SEO may suffer without supplemental measures.

Isomorphic JavaScript: The Happy Medium?

Isomorphic JavaScript presents a “hybrid” solution between SPAs and pages rendered on the server. The result is an application with the ability to serve up fully formed, crawlable HTML on the server while still maintaining the flexibility of a highly interactive JavaScript UI.

With the emergence of Node JS as a viable “server-side” language, JavaScript developers can now write modular, reusable code that runs on the server or on the client, depending on how it’s requested.

For example, a request for a company’s contact information triggered from clicking the “Contact Us” link in the navigation is processed differently than if a user manually typed into the address bar of their browser. So a search crawler would be able to parse that web page like any other static content, and the user navigating the site would trigger an asynchronous request that only loads the contact information since they’re already viewing the header and footer of the site. Sounds like the best of both worlds, right?

Is This The Future?

Well, yes and no. The concept of Isomorphic JS isn’t new but adoption rates have increased over the last 18-24 months. Several large companies including AirBNB, LinkedIn, and GoDaddy have moved major parts of their site infrastructure to a Node-based platform. Additionally, “monolithic” frameworks like Meteor have gained popularity with developers and earned financial backing from the venture community. In fact, several companies have leveraged Meteor’s quick set-up time, vast package library, and isomorphic architecture to create rapid, fully-dynamic prototypes for large-scale web and mobile applications.

Finally, this type of application architecture can provide its share of benefits, but it’s important to remember that the learning curve is notably steep. When you’re developing code to run on the client and the server in the same language, pay attention so that code doesn’t run in the wrong place. While you can run server-side JS on the client, it doesn’t always mean that you should.

The benefits of Isomorphic JS are bountiful, but it’s certainly an investment that should be weighed carefully. Today, quality JavaScript developers are in high demand to deliver feature-rich interfaces that are driven by large back-end applications. It’s tempting to draw a line to the idea that a stable of JavaScript developers can suddenly leap into the “server-side” realm with this technology, but that’s easier said than done.

This technology is gaining traction every day in the agile development community, so I encourage you to explore its possibilities and see how it can help you, your company, and your clients.