Client side rendering vs. server side rendering
Hopefully you’ve been reading some Technically in your free time, and you’re familiar with the client-server model. It’s how the whole web works: companies host their websites and apps on fancy, powerful servers, and you download files from those servers to look at in your browser. When these files are dynamic, their content changes based on who’s logged in, what’s going on, what screen you’re on, and stuff like that. This section is about how that actually happens.
When an app or website needs to send you dynamic content, there are (surprise!) two places they can create that content: on the server side, or on the client side. The server side means they populate and configure the page before they send it to you; the client side means they send you the basic HTML, and the dynamic logic happens in your browser.
In practice, the difference is in where the backend logic happens: all on the server, or mostly in the browser calling APIs on the server.
The benefit of doing things server side – in a lot of cases, it’s faster. That’s because files only need to make one trip – from the server to you – as opposed to Javascript in your browser hitting multiple APIs on the server over time to load one page.
The benefit of doing things client side – you don’t need to reload the same HTML and other boilerplate stuff every time you load a page; all that needs to change is the dynamic parts of whatever you’re loading.
Traditionally, server side rendering was the dominant form of building web applications. But as Javascript has gotten better and web apps have gotten more complicated, client side rendering is getting more popular, to the point where it’s now pretty much the default for most tech startups building their stuff from scratch. React is the poster child of that movement.
(Nowadays, things aren’t completely black and white: a new class of applications is combining server side and client side rendering into hybrid models that take advantage of the benefits of both.)
