In the 1990s and early 2000s, rendering HTML was mainly a server job. Programming languages like Java, PHP, and Perl ran as web server extensions and created the HTML and CSS that made database responses practical for end users. Servers rendered these responses at request time and, when possible, cached them for subsequent requests.
With JavaScript growing increasingly potent over time, more and more of the HTML rendering work moved into browsers. Rich web applications were popular, and features like optimistic form submissions were a must-have as they made applications feel significantly more responsive to user input. This shift also allowed the simplification of backends—if the browser did all the presentation work with JavaScript, the server could return simple data structures instead of whole UIs.
In the decade-plus since 2010, the trend has gone in a completely new direction: rendering at compile time and deploying static HTML, spiced up with JavaScript, on static web servers. As a result, you can generate files that aren’t subject to many updates, allowing users to benefit from them without having to re-render on their machine, while keeping the backends simple.
To help you find the best solution for your next project, we’ll explore client-side rendering, server-side rendering, and static site generation, including the pros and cons of each.
We will start with client-side rendering. Here the client side is the more complex part of the application, and it does all the HTML rendering work with JavaScript in the browser. The server part is an API that delivers JSON or XML to the client, and isn’t involved in HTML rendering.
This rendering technique allows for highly interactive web applications that rely heavily on unusual interactions.
Take a car sales website, for example. These sites will often have complex 3D models of their cars that allow users to view each model from different angles, open the doors, and more. This is a use case where client-side rendering will be beneficial.
Other notable examples of use cases include professional digital tools, like digital audio workstations or graphic manipulation software. These often have highly customized UIs and need to provide real-time user feedback.
The second technique is server-side rendering, where a runtime on the server generates the HTML for the clients on a request. One of the most prominent frameworks for this technique is Ruby on Rails, which uses the Ruby programming language to render HTML and connect to databases.
Server-side rendering is suitable for websites that get along with standard UI elements. While you can always add JavaScript to the client if you need a few more specific UI elements, overall, the app should use what HTML has to offer out of the box—otherwise, the app could get hard to maintain.
Server-side rendering works well for content updated with moderate frequency—for example, every few seconds or minutes.
Blogs and forums are a good example for using server-side rendering. As interactive websites, blog readers and forum members continuously create and add custom content that doesn’t contain complex UI elements that would require JavaScript. This type of content is often read by a massive number of users, so rendering once and caching for subsequent visitors can mean a huge performance gain here.
This approach also applies to more media-heavy web applications where people upload images and videos for others to view.
With static site generation, our third and final technique, the HTML is generated at compile time, for example, on a continuous delivery system. The generated HTML files then get uploaded to a static web server.
While this is the most straightforward out of the three techniques, it only works for straightforward interactions. Static site generation is mainly suitable for websites with content that isn’t frequently changed.
The ideal use case scenarios for this approach are documentation or media galleries—websites where one party creates all the content, and everyone else consumes it without actively interacting with it.
There are also numerous static site generators for blogs. If you don’t plan on frequently updating your content and don’t need a fancy comment system to connect with your audience, this approach can be a good fit for your project.
This article covered the three approaches to rendering a website along with the pros and cons of each. Before choosing one to work with, it’s best to understand your project’s goals and requirements.
Client-side rendering is the most fitting approach for highly interactive applications while server-side rendering works best with moderately interactive applications where many users consume the data of just a few content creators. Finally, static site generation suits scenarios where your goal is simply to deliver your own content (be it text or other media) to your users.
Write for Site24x7 is a special writing program that supports writers who create content for Site24x7 “Learn” portal. Get paid for your writing.
Apply Now