I almost hate to write this article, but at the same time I have experienced a special freedom lately. We build high performance single page applications, this means our web sites render data in the browser rather than the server. Over the past year we were challenged by customers to live without ASP.NET, node and other server-side rendering services. After several experiences and some changes to our workflow, we found don’t need them and neither do you.

Why No Server-Side Rendering?

You may have read articles and heard statements to the effect server-side rendering is faster than client-side. I have disputed this theory and even done some simple tests to compare the two techniques. Part of the argument is that browsers and DOM are not fast. This is untrue. They are not fast when you do things wrong, which most fast food frameworksdo. They are designed using server-side architecture and techniques, not good client-side browser techniques.

Server-side rendering is performed by an application engine like ASP.NET, Ruby, PHP, Java, node, etc. Often this involves making a call to some sort of data store and possibly evaluating authentication credentials. This can and often leads to a slower time to first byte (TTFB).

Good server-side rendering engines offer a caching mechanism like ASP.NET’s Output Caching. Here the server renders content once and caches the result in memory. Output caching allows you to declare caching parameters so you can designate the cache time to live (TTL), queryString, language and other variations. It is a powerful technique.

In essence Output Caching produces a static HTML file. Because data becomes stale over time this cache needs to be purged and rendered again. All data has a life cycle or personality as I call it that determines the right way to cache the rendered markup.

Modern single page web applications by their nature move this server-side exercise to the client. This means a SPA is responsible for managing markup and rendering as needed. They also manage data caching. These responsibilities are managed by Love2Spa, our web platform, as fundamental design features.

This does not mean there is not a dance between the web server and the client that needs to be managed. Single page applications require a different approach where the server offers more of a dumb or static server architecture. The application instead relies on a robust API to provide on-demand data, preferably in JSON format. A single page application needs a fast, static web server that beckons back to the web’s early days. The API provides the dynamic aspects of the application, data and authorized content.

This is good because static CDNs like Azure and AWS’ S3 and Cloudfront are cheap, globally distributed and fast. APIs can be built and hosted on the same cloud platform, using services like Azure App Services, Blob Storage, AWS Beanstalk or S3. Again API platforms are cheap and highly scalable. While many management tasks need to be managed in this scenario, they replace many tasks previously assigned to the web server. In my experience there is even less administration required.

So how does the modern single page application architecture look? Let’s look at two diagrams, one with a single web server and another using the distributed cloud based services previously described.

#user experience #bypassing server-side rendering altogether #better web user #experiences