All writing

Field note · Alexandru-Dan Pop

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

Learn the differences between SSG, SSR, CSR, VDOM

  • #javascript
  • #webdev
  • #react
Published
Reading time
4 min read
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:

CSR flow

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)

✅ CSR lets us render an interactive app in the browser.

❗ With an empty HTML shell, users wait for JavaScript before seeing the app content.

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.

SSG flow

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.

Hydration makes the pre-rendered HTML interactive. Navigating to another page may still fetch code or data.

✅ Static HTML can be served directly from a CDN.

❗ Updating build-time content requires regeneration. Dynamic data can still be fetched in the browser.

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.

SSR flow

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. Generating HTML per request adds server work; caching can reduce it.

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.

❗ Request-time rendering adds server work and scaling concerns. Static assets can be served from a CDN; backend APIs still need to handle their own 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 the UI. React compares render output and commits the necessary DOM updates. Rendering a component does not mean replacing its DOM nodes.

YouTube embedLoad this embed when you are ready to view it.View on YouTube

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 🔥🔥.

© 2026 Alexandru-Dan PopSoftware · AI · Product