Client-side Rendering Pros and Cons

This discussion came up at Trippeo about whether we should rewrite the web dashboard to use a modern framework. A few of the developers held differing opinions about whether switching to client-side rendering would be beneficial. I did not even understand what client-side rendering meant. I spent two days reading up on the topic. At one point I had over 15 tabs open in my browser! It can be a little overwhelming when one article leads to another and then every article has new terms you need to google. Although a lot of the information went over my head, I feel I have a better understanding of client-side rendering now.

Here is a summary of my notes:

Client-side rendering is when the client-side environment is used to run scripting. The source code is transferred from the web server to the user’s device and then run, typically in a browser.

Server-side rendering is when the web server runs the scripting language. The web server runs the script to create dynamic HTML pages which are then sent to the client’s browser.

PROS of Client-side Rendering (1, 2, 3, 4, 5, 6)

  • Faster navigation If data does not need to be loaded, clicks and interactions are much faster since the entire payload is loaded up front. “Last paint time” is much shorter.
  • Server performance Traffic and server load can be decreased. The server only needs to deliver static files and answer API calls with JSON. Server performance can be improved with good use of JSON and client-side caching.
  • Architecture The front end is almost completely decoupled from the backend. The framework needs knowledge of the REST API. The server needs to deliver static files (html,css, javascript) and pre-render screens when crawlers are present (less of an issue with Google starting to crawl JavaScript files). But, they do not need internal knowledge of the other and can be done on the same or completely different server. The browser becomes a consumer of the API, just like a iOS or android application. The backend and the frontend can be developed separately from one another.
  • Improved development speed No matter which approach (server side or client side rendering), html/css/JavaScript are required. With client side rendering, knowledge of server-side programming languages is not required. This makes the work of front-end developers(who don’t have backend skills) easier. The amount of code can be reduced and the need to recompile the backend code is eliminated. (Changes to the front end can be seen almost immediately)
  • Testability You can build out the entire view layer of your app without firing up a server. (Put your mock data in a JSON file.) This mock JSON can also be used for testing.

CONS of Client-side Rendering (1, 2, 3, 4, 5, 6)

  • Slower Initial Load The browser needs to do the extra work of manipulating the DOM elements, binding data and watch for changes, do additional REST requests to the server … etc. All the JavaScript files need to be loaded the first time the application is opened. This may be a problem for more complex applications. Initial experience can suffer. “First paint time” is much longer.
  • Unpredictable Performance The performance of your server is much more predictable than all the different user devices. Are your users going to be using your application on mobile devices? Slower connections? Old computers? It takes time to download, evaluate, and run the JavaScript before the user will see anything (Initial load time). This is not optimal for users who do not have the latest and newest and can cause a frustrating initial user experience. (This concern depends on your user demographic.)
  • Compatibility with older browsers If you care about legacy browsers, with the biggest concern being Internet Explorer(<IE8), alternative pages will need to be served. This takes additional development time. What about environments where JavaScript is disabled? (Some screen readers, users who have JavaScript turned off.. etc.)
  • Search Engine Optimization Pages have to be pre-rendered on the server for crawlers and indexing. The good news it that Google has started to crawl and index sites in JavaScript so this is becoming less of a concern.
  • Maintainability While the ideal scenario leads to a clean separation of concerns, application logic and view logic may end up duplicated between client and server in different languages. Examples of this could be date formatting, currency formatting and form validations. This makes maintenance of complex apps difficult.

Question: Does there have to be a tradeoff?

Why not render the initial state of the page on the server, and then re-render the parts that need to be updated on the client? Biggest reason: server-side rendering and client-side rendering typically isn’t mixed because they are written in different languages.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s