Web Development: What Are The Trade-Offs Of Client-Side Rendering Vs. Server-Side Rendering?

Since GoogleGoogle Plus and a few other cutting-edge websites now render entirely on the client, let’s review why server-side rendering is desirable at all.

Server-side rendering means when the browser fetches the page over HTTP, it immediately gets back HTML describing the page. Server-side rendering is nice because:

Your content is visible to search engines like Google.

The page loads faster. There’s no “white page” while the browser downloads the rendering code and data and runs the code.

It maintains the idea that pages are documents, and if you ask a server for a document by URL, you get back the text of the document rather than a program that generates that text using a complicated API.

Client-side rendering means JavaScript running in the browser produces HTML or manipulates the DOM. The benefit is you can update the screen instantly when the user clicks, rather than waiting a few hundred milliseconds at least while the server is contacted to ask what to display. Sites where you mostly navigate and view static content can get away with mostly server-side rendering, but I can’t think of any website that doesn’t do any client-side rendering. Any portion of a page that’s animated or highly interactive (a drag-able slider, a sortable table, a dropdown menu) almost certainly uses client-side rendering.

People don’t usually realize there doesn’t have to be a tradeoff. Why not render the initial state of the page on the server, interactive widgets and all, and then re-render the parts that need to be updated on the client? Though it’s typical to render the meat of a page on the server and then “enhance” it on the client with a library like jQuery, it’s rare that a site performs the same rendering tasks on the server and client as appropriate.

The reason server-side and client-side rendering aren’t typically mixed is that they are typically done in different programming environments, usually in different languages. For example, almost all websites render the overall page layout and the content, such as blog posts, on the server, generating HTML in a language like Ruby, PHP, or Python. On the other hand, a chat widget or an image gallery might be written entirely in client-side JavaScript, while a slider or a rich text editor certainly would be.

For websites that blend static, navigable content and app-like interactivity (or for companies that seek to provide an added measure of sanity for their engineers and designers), this divide becomes a huge pain. This is why Google Plus does all rendering on the client. Quora cleverly does almost all rendering on the server (including when you, say, click a “Follow” button), but only the updated parts are sent to the client. (Particular widgets like the editor and “Promote” slider that provide instant feedback are clearly client-side.) In an effort to increase responsiveness and flexibility, many sites now render Ruby templates on the server and Backbone templates on the client for different parts of the same user interface. AirBnB has experimented with running client-side JavaScript templates on the server.

With server-side JavaScript on the rise, I believe the solution is simply to have a single UI framework that runs on both the client and the server, generating the initial HTML on the server and providing an interactive experience on the client. I’m working on bringing such a framework to Meteor, which already unifies other APIs between the client and server such as fetching a URL or querying a collection of data.

In the absence of such a solution, programmers usually end up arguing either that client-side rendering isn’t very important (because most sites or apps consist of large “pages” or “screens” and a round-trip to the server is acceptable when navigating between them), or that server-side rendering isn’t very important (because an all-client app just needs a loading screen and a little extra attention to search engine optimization). These arguments are motivated by the pain of having to deal with both types of rendering in the same application when they involve different languages and APIs.

More examples of major sites and their rendering strategies: FacebookFacebook is mostly PHP but certain parts of the UI are pure JavaScript — the chat, the comment form, probably the photo gallery. Gmail is written in something like C++ or Java, and I’m not sure where the rendering takes place, but I’d guess it’s mostly or completely on the client (given the progress bar it displays while it loads). The old or “basic” Gmail view is presumably server-side rendered. Github’s Markdown implementation is written in C and runs on the server. StackOverflow has two Markdown implementations, one for live preview on the client and one for the server.

Post Your Comment

Post Your Reply

Forbes writers have the ability to call out member comments they find particularly interesting. Called-out comments are highlighted across the Forbes network. You'll be notified if your comment is called out.