FE Jargon you should know - SSG, SSR, CSR, VDOM

If you have heard lately talks about SSG, SSR, CSR, VDOM - and you were like:

What the heck is that?

Then this article is for you and aims to be a mini dictionary for modern frontend terminology and jargon.

Please leave a & if you enjoy this article & follow me on Twitter where I post more cool content.

CSR

Client side rendering

The general way of building frontend applications those days is writing them using libraries like React, Angular, Vue, or Svelte and then building them in a javascript bundle. This bundle is referenced in our single HTML file. CSR (client-side rendering) is rendering our markup in the browser. If that sounds complicated, look at the image below:

This image represents two stages:

1. Dotted gray line represents the deployment of our FE code to a server. As you can see the deploy step generates an HTML file and a bundle.js file.
2. Dashed green line represents how a browser gets to paint our app:
   1. Browser - STEP 1 - The browser requests the HTML file
   2. Browser - STEP 2 - The browser requests the JS file
   3. Browser - STEP 3 - Perform Client-side rendering (CSR)

As an advantage - CSR is the most straight-forward way to build a SPA (single page app). So it's the easiest and fastest way for developers.

The main disadvantage of this approach is that after Step 1, we cannot show anything to the user. We need to wait until JS is downloaded, parsed & executed (Step 3), and only then our users can see the app.

SSG

Static site generation - this is when you are pre-rendering a website with a framework or library that is producing static HTML pages.

For example, you could be writing a React application, but you want its output to be static HTML pages. This might be because you enjoy React, but you also want the performance of pre-rendered content. Something like a blog, a presentation website, or an e-shop.

If the content doesn't change often, it makes sense to render at build time, instead of loading all the javascript in the browser and only then building the HTML that the user will interact with.

Comparing to CSR -> you can see we have lots of HTML files resulting from our build step. We also have HTML available to render in the browser in Step 2.

Additionally, SSG sites can be hydrated after the initial page is loaded.

Ok, if that sounded weird, that just means after the initial HTML page is loaded, it can also load the CSR library so when the user navigates to the next page, it happens instantly, rendered on the client, without other network calls.

SSG sites will create the most performant web apps provided the hosting is also good.

Content needs to be fetched always at build time. This means we need to build & deploy every time the content changes. This is not feasible for highly dynamic content.

SSR

Server-side rendering
Server-side rendering is a pretty old technique. Any application that renders HTML on the server can be called an SSR app.

But this looks like the SSG pic...

Hmm.. kind of, but here you can see we actually don't treat our server just like a dumb provider of static content, instead we are actually doing something useful with it. We are generating the HTML every time our user needs it. This is slower than SSG because the server needs to compute the HTML.

The generic code that runs on a server in this picture could be a Node.js Express App or Ruby or Python. The thing that we achieve with this approach is the dynamic control of our content, headers & meta tags (that can serve for SEO). And a plus can also be the performance. We don't stress our app consumers downloading a bunch of JS and only then rendering HTML (CSR), we give it straight away. The caveat is that we need to account for the fact that our server needs to be performant doing the generation & also support the load we throw at it.

SSR sites provide us the most flexibility in terms of what we want to display to users despite fast content changes & how we optimize our response headers & meta tags for SEO.

Extra complexity due to the server-side code & we need to scale our server in case we receive more load. SSR and SSG don't have this problem, they can be thrown on a good CDN and that just scales to any load.

SSR, SSG, CSR - can be combined.

Modern frameworks like Next.js (for React) or NuxtJS (for Vue) allow us to write applications that can serve multiple purposes and we can combine those techniques with it.

VDOM

Virtual DOM
The Virtual DOM is an in-memory representation of our UI elements. Frameworks like React, Angular & Vue use a Virtual DOM to not paint in the real DOM the same thing multiple times. Because the real Browser DOM is slow to paint things, those frameworks use a VDOM as an optimization to keep track and only re-paint the things that are necessary.

Next article

The next post will be more about:

• Micro-frontends
• Building & bundling related topics - CodeSplitting, Transpiling,Tree shaking

For React specific things to know - I wrote about it in-depth in my other article.

For a description of more general concepts - you should also read the very nice Web Nerd Terminology blog post on CSS tricks.

Conclusions

Hope those explanations help - please leave a & to support the effort of creating this article.
More cool content on Twitter .

Comment below

Do you use SSR, SSG, CSR, or all of them?