A decade ago, nearly everyone was rendering their web applications on the server using technologies like ASP.NET, Ruby on Rails, Java, and PHP.
Then handy libraries like jQuery showed up, and suddenly server-side rendering everything didn’t necessarily make sense anymore. jQuery was followed by a long list of client-side libraries like Backbone, Knockout, Angular, Ember, and React. With each iteration, client-side rendering grew easier and more powerful.
This style goes by many names: Single page apps, SPAs, JAM stack…call it what you will. The point is, today, client-side rendering has become the de-facto way to build rich web applications…But why?
Hey Everyone, Let’s Do It The Hard Way
There’s no denying that client-side rendering is harder to do well. You have to think about bundling, transpiling, linting, cache busting, and so much more. Doing client-side right is so hard that I walk through over 40 decisions you need to make to get all this right in my new Pluralsight course.
So why are we subjecting ourselves to such pain? Because client-side rendering offers a long list of benefits that server-side rendering just can’t touch.
Here’s why client-side rendering won.
No Full Page Reload Required
With traditional server-side rendering, the server responds by generating and returning a completely new page for every interaction. This often slows load time, uses more bandwidth, and creates a less responsive user experience.
Client-side rendering avoids making unnecessary requests for a full page when only a portion of the page has changed. This is especially helpful in a world that’s increasingly browsing via mobile networks with high latency.
Client-side rendering supports lazy loading sections of your application to save bandwidth & speed initial load. For example, you can load additional records, images, and ads as the user scrolls down, or as the user changes their search parameters, all without performing a full postback.
Hosting static files is typically cheaper than hosting traditional server-side technologies like ASP.NET, PHP, or Ruby. You don’t need much horsepower to serve a static file. Serving static files is so cheap in fact, that a variety of solid free options exist including Surge, Firebase, and Netlify.
Use a CDN
A static front-end can be hosted via a content delivery network (CDN). CDNs deliver improved performance by globally distributing assets as well as improved scalability by removing load from your webserver. The aforementioned static hosts utilize a CDN.
Static files are easy to deploy. You don’t necessarily need to perform a monolithic build to generate new binaries when a small change occurs. And with some of the aforementioned services like Surge and Netlify, you can easily create automated deployments via their provided CLIs. When you do so, you don’t risk breaking any of your back-end – it’s handled completely separately.
Enforced Separation of Concerns
Many teams struggle with keeping data access and business logic out of the user interface. With client-side rendering, separation of concerns is programatically enforced. There’s no way to directly hit the database. You have to make a call to a separate service. This helps foster a service-oriented mindset on development teams since there’s no way to make a short-cut and call the database directly from the UI.
Learn Once, Write Everywhere
This is why it will continue to swallow the world.
Same UI Technology for Web, Native Mobile, and Desktop
For instance, you can use Angular, Ionic, and Electron, to work in Angular for all three targets. Or, you can use React, React Native, and Electron to work in React for all three targets. And the resulting applications will run on iOS, Android, Windows, and macOS. Sure beats learning Objective-C, Swift, Java, C#, WPF and more to support all these platforms!
Edit — I had a point here about Progressive Web App support but was incorrect. You don’t need to do client-side rendering to build a PWA.
So. Much. Free.
Does Server-Side Rendering Make Sense Anymore?
Sure. But in far fewer situations than before.
If you’re building a mostly static site, server-side rendering might be easier. Though awesome tools like Jekyll, Gitbook, Gatsby, and countless alternatives are encroaching on this area too. And since tools like these just generate static HTML, you don’t have to worry about SEO impacts either.
SEO is a common selling point for server-side rendering, but the advent of isomorphic/universal rendering in libraries like React has addressed this concern as well. Universal rendering used to be hard, but modern tools like Zeit’s next.js finally make this trivial as well!
Given all the advantages above, I struggle to find good reasons to do traditional server-side rendering anymore.
Sure it’s still hard to do well. But for all the reasons above, client-side rendering won.