It is time to abandon server-rendered HTML

There are many, many benefits, to building your business on API’s. Easier B2B interoperability, separation of presentation and business logic, as well as the natural varying velocity of API vs. UI development, are all arguments cited as to why you should present some form of API for your business. API’s are a good – if not necessary – part of the competitive landscape.

Historically, however, most web application development still begins with server-rendered HTML. As evidenced by frameworks such as Express, Django, or WordPress, the ability to render data to browser-ready HTML remains a core part of our development process. This is not surprising – in the early days of the internet, most of the computing power was available only on servers, and implementing complex user interface logic onto a browser was both poorly supported and immature.

We have come a long way since then. Standards – be it RFC’s, WhatWG documents, or W3C standards, have evolved to chip away at the need for HTML to be provided by the server. In 2014, the CORS specification broke down the single-origin policy barrier. The maturing of HTML5, and its adoption in modern browsers, has filled in key feature gaps and converted the web browser into an application platform. And, finally, the rise of browser-based application frameworks such as AngularJS and React, provide a much needed toolkit for manipulating HTML directly in the browser.

There remains one argument in favor of server-rendered HTML: Search Engine Optimization (SEO). Web crawlers are notoriously bad at dynamic web pages, and thus a long-standing `best practice` in my industry has been that all public content must be crawlable. There were some bridging technologies – such as the ?_escaped_fragment_ contract recommended by Google, however even those pushed the onus of generating static content to the server.

And then, on October 14th, 2015, Google deprecated their AJAX crawling API. Quote:

“Today, as long as you’re not blocking Googlebot from crawling your JavaScript or CSS files, we are generally able to render and understand your web pages like modern browsers.”

Let’s be honest: Google is the gorilla when it comes to web crawling, and it’s only a matter of time before other search engines will follow suit (if they haven’t already). Web apps, be they simple or complex, can now be fully understood by a crawler, including any content provided by an API.

So… why are we rendering HTML on the server? Static content- be it static HTML or a complex AngularJS app – requires no server resources. In fact, you can host your entire application in Amazon’s S3, point a CDN at it, and it’s available globally. The alternative – paying for regionally placed UI servers – is by comparison unjustifiably expensive.

It is time for this technical approach to be retired. Treat your web page like an API client, no different than your mobile or desktop app.



Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.