Google Developers
Published in

Google Developers

Tradeoffs in server side and client side rendering

Originally published on my blog Industrial Empathy.

For a long time there has been a debate in web development as to whether web apps and sites should be rendered on the server or the client — or, of course, both.

With a recent post by PPK the debate flamed up again and one thing that struck me as particularly unhelpful was the argument that where something is rendered would be automatically determine whether a given framework is (one dimensionally) good or bad. In my opinion such an simplistic view on things hides the real underlying tradeoffs that should drive decisions.

For some perspective: My day job is building web frameworks for Google. The one I’m designing is from the ground up build to support server side rendering very well (it isn’t open source mostly because I felt Google had enough open source web frameworks already and I didn’t want to make the choice even harder, but I also never want to say never). So, it may seem that I’d be somewhat “partisan” with this respect, but the opposite of true. My framework comes with a disclaimer saying that it is particularly designed for very large consumer-facing web applications. Anything that doesn’t fit that description might still be happy, but there will be tradeoffs made that make their life more difficult than otherwise necessary.

First I’d like to establish that server side rendering is hard beyond the pure ability to render on the server. Assuming you are building a complex app that wants to render initial responses on the server and then update subsequent state using XHR, there are several challenges that a good server side rendering solution needs to overcome and complexity that is added in any case:

  • Client side decoration. It is great that you can render a chunk of HTML on the server, but you also need to do things like registering events handlers on the client. Many modern frameworks do that during rendering. One approach is to just immediately after load do a client side render using the same data that was used for server side rendering. React makes this quite nice. But this now means that loading the code that is necessary to make the page interactive includes the code that is necessary for client side rendering (read your templates!) and with that a major benefit of server side rendering is gone.

I could go on, but the gist is: server side rendering comes at complexity cost because while all of the issues above can be eliminated the solutions will add very significant complexity to your project.

So why would you do server rendering:

  • Some people say that search engines still like it better.

Looking at the benefits of server rendering there are entire classes of apps that don’t benefit from it at all:

  • Your intranet ERP, HR, Financial, blah software will not want Schema.org markup. In reality most software that is being written falls into this category.

The most obvious class of apps where server side rendering would have major benefits are content publishing sites like the New York Times or, you know, Medium as well as other user generated content sites that rely on referral traffic for perma link pages (Think Instagram, Youtube, Twitter, etc). As one of these the amount of engineering I’d be willing to take on to make my pages just a bit faster, friendlier to BingBot and easier shareable on other social networks may be pretty high. That it may not be high enough can be seen on Instagram which is not server rendered (Update 2016: It is now server rendered using the fastboot pattern. Faster but requires a lot of CPU per page load); I’d not be suprised if that changes in the future, but it seems for them shipping was more important than ultra high fidelity.

I’m excited that Ember.js is adding server rendering. I’m sure they’ll do a great job hiding the complexity, but this decision will still impact their project in the long term:

  • Some stuff just won’t work on the server. That has to be documented somewhere. People have to read those docs.

In the more general case there are dozens of tradeoff spaces in which frameworks can make decisions as to what they want to optimize for. Some frameworks have data binding which is awesome if your app has lots of forms and getting shit done is super important and more important than making UX absolutely perfect— in that case adding each event handler one-by-one may not be cool — on the other hand if your job is to build the Facebook image upload dialog you may have a UX team and 2 engineers twiddling every last aspect for multiple months. These are very different types of software and even though both may be rendered from HTML, I’d use a very different underlying system to build them.

In conclusion: Server rendering is great, use it where applicable but be conscious about the hit in productivity due to extra complexity and decide whether it makes sense for your app.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store