Here’s Why Client-Side Rendering Won

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.

Just a few reasons client-side development is challenging.

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.

Lazy Loading

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.

Rich Interactions

Client-side rendering supports rich, animated interactions, transformations, and transitions. Fade a row out on delete, or fade a dialog into view. Sure, you can sprinkle such goodness into a server-rendered application, but this often leads to maintaining the same template on both the client and the server, or managing the complexity of weaving JavaScript interactions in with a server-side framework.

Cheap Hosting

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 SurgeFirebase, 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.

Easy Deployments

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.

Easy automated deployments? Yes please.

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

Imagine you’re a new graduate. What is the only language that will allow you to build web applications, APIs, mobile applications, and desktop apps? JavaScript. Increasingly, that’s precisely what new grads are reaching for. Why should a new grad learn a dedicated server-side technology when JavaScript runs everywhere?

This is why it will continue to swallow the world.

JavaScript is like Visa. It’s everywhere you want to be.

Same UI Technology for Web, Native Mobile, and Desktop

Imagine you want to build a SPA-style web application, a native mobile app, and a desktop app. Today’s modern JavaScript frameworks allow you to use the same UI technology for all three scenarios.

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!

I’m pretty sure these umbrellas spell JS. Somewhere.

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.

JavaScript moves so fast that the hardest part of client-side rendering is choosing how you’re going to get it done. The number of free options is simply overwhelming and growing fast.


Yeah, it’s a great problem. And there’s no need to pay for the libraries, frameworks and editors your team needs. I walk through and set up dozens of useful free tools in “Building a JavaScript Development Environment”. (free trial)

Does Server-Side Rendering Make Sense Anymore?

Sure. But in far fewer situations than before.

If you need interactivity and can’t rely on JavaScript, then obviously client-side rendering is out.

If you’re building a mostly static site, server-side rendering might be easier. Though awesome tools like JekyllGitbookGatsby, 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.