FacebookLinkedInShare

In the beginning… there was server rendering. When a user typed a url in to their browser html was delivered to the browser as a whole document. When a user requested a new page after clicking a hyperlink, a new page was delivered with complete HTML including head, body and all frontend scripts that were necessary. When search engines had to spider the website it read the sitemap.xml and processed all pages each time receiving a new fully formed HTML document. This was great from an SEO perspective as the document rendered on the server contained all necessary elements to use for search engines.

As pages became vehicles for more than simple text and images and the demands made on the html specification increased, wait times for pages also increased. Enter the advent of AJAX or asynchronous JavaScript. Now a user could click on a link and instead of the page being refreshed and a new complete document being returned from the server, the payload could be either an html fragment or JavaScript to manipulate the state of the existing document.

From this development came the single page application where are all pages requested by the user generally followed a main controller using a combination of MVC approaches to route the user to the requested page. Hailed as a revolution in website development and coming in tandem with a plethora of JavaScript frameworks such as Backbone, Angular, Ember and later React.js this technology also came with several disadvantages.

Initial page load time of a website is a key factor in a users engagement level in a site and in this day of Gigabit network speeds even an extra second can come with negative revenue potential and user dissatisfaction. When a user first requests an un-cached single page application (SPA) all scripts must be loaded into the browser which causes a significant delay. Aside from CDN caching, workflow tools such as Webpack and Browserify have been developed to among other things allow a SPA to break up codebases into smaller pieces reducing the amount of code that must be transferred to a users computer before a site can function properly.

Another pitfall of SPA’s are the lessened ability of search engines to spider content; this can have a serious effect on a company’s bottom line.

State management is an important aspect of SPA development with each framework handling this idea in a different way. With the older generation of JavaScript frameworks state was maintained by comparing DOM elements and looping through the DOM to check for changes. This dependency on the DOM causes many problems with performance and stability.

To alleviate these issues a number of new frameworks have emerged or are emerging that handle state in a way that abstracts the DOMĀ and allows a more flexible approach to SPA development. One very exciting offshoot of these new technologies is the ability to render client JavaScript on the server; enter universal JavaScript.

With universal JavaScript a server can render the page the first time a user requests it allowing for radically reduced initial page loads. Once the user begins to interact with the SPA the server reverts to just passing back the asynchronous data, thus we have the best of both worlds with none of the downsides.

Some other of the advantages to this technique are:

  • the ability to share code between the client and server such as routing, validation etc.
  • the ability to provide search engines with tailored seo information
  • tight integration with modern JavaScript workflow tools such as webpack, browserify, npm, grunt, gulp and the assorted modules and addons for these tools

React.js is one framework that is leading the way with a wide array of starter projects that integrate server rendering using Node.js. Ember.js has also been working on a similar strategy named FastBoot however it is still far from production-ready. There were also rumours of Angular.js 2 server side rendering support however implementation details are as yet vapourware.

Though there are examples of rendering client side JavaScript using server languages other than JavaScript, the vast majority of projects are using Node.js/io.js and Express/Koa. As Node.js gains more popularity and universal JavaScript becomes more battle-hardened it remains to be seen whether server rendering of client javascript code on other server side languages will catch on like it has on Node.js.

Further Reading:

http://nerds.airbnb.com/isomorphic-JavaScript-future-web-apps/

https://facebook.github.io/react/

http://isomorphic.net/

http://emberjs.com/blog/2014/12/22/inside-fastboot-the-road-to-server-side-rendering.html

https://github.com/reactjs/react-rails

https://github.com/reactjs/react-php-v8js