Server-Side Rendering is a Thiel Truth
I recently pondered how I'd answer Peter Thiel's interview question if my answer had to relate to software:
What important truth do very few people agree with you on?
My answer: server-side rendering is a better choice for many applications:
- it's cheaper to implement
- it's easier to make correct
- it's often as fast, or its performance characteristics are different but acceptable.
- users would prefer your app as a website
Does it feel uncontroversial to you? I'm glad, but ask yourself: how often you encounter React 'apps' that are a couple of forms? Links you can't open in new tab? Loading spinners before a deep link on an e-commerce site renders? It certainly appears the industry disagrees in practice.
Client-side rendering has boomed for the decade I've been in the industry (and I've done lots of client-side). People newer to the industry might never have built a server-side rendered app, so it's not an open question for them. As a result, for most client-side rendering is uncontroversially the 'right' way to build software.
I think they're wrong: server-side rendering is more often the better choice.
Why?
Cheaper
You will need a backend anyway. It'll need to expose data to users. Exposing it as HTML is no harder than doing it via JSON or GraphQL. The data to HTML transformation is still required with client-side rendering, so client-side saves no work, but imposes its own costs.
Correctness is easier
You avoid the hard problems particular to client-side rendering. Your client-side will have its own state to consider on top of the state in your backend, and state is what makes programming hard. It's long-lived state (versus an HTTP request handler), so resource leaks and inconsistency will be more of a problem. You are writing a distributed system: the state on the client and server are not magically in sync.
The less this all seems scary to you, the less complex your client-side is, and thus the less justification there is for client-side rendering.
As fast, or faster
Client-side apps are wads of Javascript that must be loaded and parsed before it can load and parse JSON which it can then transformed into HTML. Precisely nothing about this is optimal for browsers and networks. Many applications are used infrequently and browser caches are not magic (and disagree with you about how important you app is), therefore arguing 'each user only has to load it once' is bullshit.
Unless your app is something used frequently and for a decent period, with lots of low-latency interaction (forms do not count: think editing, iterating), it will certainly be faster server-side rendered.
People don't want to install your app
Many important, profitable, applications aren't used enough to make a native mobile app worthwhile. Most online shops, banking, festival ticketing, government forms, etc. Therefore you will not have to support both server-side rendering and an API for your native apps
Takeaways
Client-side rendering is (obviously) necessary to support complex interactions with extremely low-latency: Figma or Google Docs could only be client side apps.
It is useful for write-heavy applications people use interactively for long periods: email, chat.
It is harmful for read-only, or read-mostly applications. Harmful to the implementors as it imposes unnecessary cost, harmful to users as it's likely slower, less likely to use the web platform correctly and less accessible. Inappropriate use of client-side rendering is why to find out my electricity bill I have to wait ~10 seconds while a big React app loads and then hits up 5 REST endpoints.
So is your app mostly forms or displaying content? User preference panels? Mortgage applications? Implement it with server-side rendering with a sprinkling of JS to implement widgets the web lacks. If only part of your app requires low-latency interactions, use client-side rendering only there.
p.s don't believe it can be fast? Have a quick wander around the D Forum - it's many, many times faster than most client-side rendered apps I use. Oh and GitHub (source: I worked there) is overwhelmingly server-side rendered (with Rails, gasp), and so is StackOverflow. It's quite surprising that this is a Thiel truth.
Thanks to Andy Appleton for review and suggestions.
I really like your article and would love to see more people choosing SSR (again). Usually these frameworks are less complex to understand and allow us to write webapps easier and simpler, still minding good development and quality practices. ThoughtWorks has choosen to encourage people to not have SPAs by default anymore: https://www.thoughtworks.com/radar/techniques/spa-by-default
Leave a comment via Github 💬