Client-side vs. Server-side vs. Pre-rendering for web apps

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.

Client-side rendering

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.

Pros of client-side rendering

• Users are charged for the rendering resource because everything is done in their browser.
• The application is always up to date since rendering only takes place when someone uses it (no stale HTML that you rendered at deployment time).
• It’s easier to distinguish between backend and frontend concerns: If it’s UI-related, it goes into the client; if not, to the backend.
• It’s the easiest way to create rich, interactive experiences because not every input needs to go to the server for processing.
• The backend can be more straightforward than with server-side rendering because it only has to deliver formatted data and no HTML.
• It makes hosting simple because only a static file host is required.

Cons of client-side rendering

• It requires more performant client devices. Clients have to execute JavaScript code and not just display static HTML.
• It slows down the first render because you must deliver the whole rendering machinery to the client.
• Caching is an issue—clients can cache for themselves and not other users. This means every user has to render HTML that has already been generated on multiple other clients.
• If you rely on search engine traffic for your application, optimizing for search engines with a client-rendered application can be a challenge.

Server-side rendering

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.

Pros of server-side rendering

• Easier to optimize for search engines: The backend delivers finished HTML pages that search engine crawlers can easily digest.
• Similar to the previous technique, the app is always up to date—provided caching isn’t disrupted due to continually rendering on request.
• The server can cache pages used by many users. While this doesn’t work for private chats, it’s still a huge plus for public forums and blogs.

Cons of server-side rendering

• The server needs to be more performant than client-side rendering; the client does almost nothing.
• You can’t use static web hosting services, as you’ll need one that can run your server-side programming language.
• User interactions are limited with server-side rendering: Only standard HTML elements are available, and everything that needs additional JavaScript in the browser can make the application unwieldy over time.
• In case you want to avoid client-side JavaScript altogether, each change to the page will need a round trip to the server. If the client has an unreliable internet connection, this can quickly turn into a problem.

Static site generation

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.

Pros of static site generation

• This is another technique suitable for search engine optimization because the content search engines receive is the finished HTML.
• It offers quick delivery, as the web server only has to send the HTML without JavaScript overhead.
• The website is rendered once and can then be delivered to all clients, which allows for free caching.
• You can use a simple static web server to host the website.
• Because the build server is the one accessing the database and not the web server hosting the website, an attack on the web server doesn’t give access to the database.

Cons of static site generation

• It carries a high risk of stale content. Using client- or server-side rendering, content is rendered on demand for every request, but with static site generation you have to create a version explicitly.
• There’s a higher performance demand for the machine that renders the page. You will generate all pages in one go, so with heavier pages updating the rendering can take some time.

Summary

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.