There’s an old adage in the Java community: Write once, run anywhere.
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:
- 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.
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 www.abc-co.com/contact-us 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.
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.