What is the difference between server-side and client-side rendering?

Question

That question has a lot of articles around the web discussing it, but given how recent I am to web dev I think I am missing a few pieces to get the full picture.

My understanding is as follows:

Let us assume we have a Node.js server and we're using express for our web app. Client rendering is when I don't enter a URL in the web browser that creates an HTTP request to my server. Instead, the client requests comes from a JS script(that was loaded from the server initially when I accessed the application using the root route for example: http://localhost:SOME_PORT/). So, let's say my request is to fetch some information about a certain user from a database. Instead of going through the server, the JS script(using AJAX) for example does an XMLHTTPRequest directly to the database(say I trigger this by a button called Fetch) instead of going through my server and then the client(the browser) will get a response and in turn will create an HTML document and render it. As opposed to server-side rendering, where I for example enter a URL in the browser, and the server intercepts the request, and prepares the HTML document along with the data requested(if any) and sends it back in HTML form for the browser to render(hence server-side, no work was done on the client-side but actually displaying the page).

Is this accurate? What am I missing in my understanding of both and when to utilize either style?

Answer 1

Both rendering techniques aim for one goal (display the page / resource you requested)

• In SSR: you request a resource HTML page from a server (by typing URL, clicking a link, googling, etc...). The page is loaded in your browser (client), note that this page has also some files to fetch (static files) like CSS, images, JS files, local fonts (if any), and so on. Now, you made an HTTP request to display the HTML document (say index.html page), now your HTML document will make automatically some other HTTP requests to bring the static files. The server will return back all the fetched files as responses, and your browser will simply display them.

Note here that we're requesting a whole document that brings with him some whole files, keep that in your head. One easy example for that is loading a webpage for the first time.

Due to the nature of SSR, and since you're requesting whole files, if the HTML & CSS sizes are big, the page may take some time loading. Even worse, if the JS files are big, you may have HTML & CSS but a nonfunctional website for a couple of seconds until JS is completely rendered (there are solutions to that but I'm talking in terms of vanilla technologies for now)

• In CSR: You're again requesting some data from the server, but not necessarily to be whole files, and these requests are usually made by your JS files using DOM & BOM (not all requests made by JS DOM & BOM are CSR, but all CSR are made by JS DOM & BOM, know the difference).

For Example: assume you have a document which is loaded, the document contains a button, once it's clicked, it will fetch a name from your database and show it in your document. Here look, you have the document already ready & loaded, but you need to bring the name from the database and change it in the document. Consider this pseudocode:

let name = document.querySelector("#name");
let newName; // Some xhr request code that I dont remember
name.innerContent = newName;

This is CSR!

Let's take this a step further, what if we make our HTML document a blank page and make our JS file generate all the content? This is also a CSR!

The advantage is: you request some data not whole files so you get a faster response, but the document / template you're building on (first thing loaded) sometimes can be blank or semi blank, which means that no keywords will be in the document, which means SEO will not find your page (Next.js & Nuxt.js solved this problem).

You'll find CSR used a lot with login pages, after you login. While SSR is used in small lightweight applications.

Answer 2

Let us assume we have a Node.js server and we're using express for our web app.

It doesn't really matter what software you use on the server, but we'll use that for the example.

Client rendering is when I don't enter a URL in the web browser that creates an HTTP request to my server. Instead, the client requests comes from a JS script (that was loaded from the server initially when I accessed the application using the root route for example: http://localhost:SOME_PORT/).

That would have loaded an HTML document which loaded the JS with a script element. You wouldn't load the script directly.

So, let's say my request is to fetch some information about a certain user from a database. Instead of going through the server, the JS script(using AJAX) for example does an XMLHTTPRequest directly to the database

No. You still make an HTTP request to the HTTP server.

(say I trigger this by a button called Fetch) instead of going through my server and then the client(the browser) will get a response and in turn will create an HTML document and render it.

Ish.

The client already has an HTML document. With client side rendering, the DOM generated from that document is modified (usually with new data requested from the server).

As opposed to server-side rendering, where I for example enter a URL in the browser

To keep the scenario as close to the Client-side rendering example as possible, let's say you click a link instead of entering a URL.

, and the server intercepts the request,

The request is explicitly made to the server, it isn't intercepted. That would imply it was intended for somewhere else.

and prepares the HTML document along with the data requested(if any) and sends it back in HTML form for the browser to render(hence server-side, no work was done on the client-side but actually displaying the page).

Basically.

---

The short version is:

With server side rendering, a complete HTML document is prepared on the server and delivered to the browser.

With client side rendering, the DOM is manipulated on the client to produce the same document.