SSG, SSR, SPA...
If you’re new to the JavaScript ecosystem, you’ve probably seen these acronyms and wondered what they actually mean in practice. Don’t sweat it. By the end, you should have a clearer mental model for how each approach works and where it shines.
SSG
SSG, or static site generation, is the process of a site’s pages at build time and outputting static files the . The paradigm is not new; if you are familiar with tools like Jekyll, you are in a good spot. The implementation details vary by framework, but the general process looks something like this:
In a typical SSG flow, your framework takes source files (templates, components, markdown/content, and data), runs a build, and outputs deployable static assets. Those assets are then served from an origin and often cached at the CDN edge for fast global delivery.
Many modern JavaScript meta-frameworks include this capability out of the box. Build and deploy steps are commonly triggered by Git pushes or webhooks in CI/CD pipelines.
SSR
SSR, or server-side rendering, is the process of a page on the server at request time and returning HTML for that specific request. Unlike SSG, where pages are generated at build time, SSR performs rendering dynamically when a route is requested. You can think of it like this:
As with SSG, implementation details vary by framework. At request time, the server fetches data, renders HTML, and returns that HTML (plus CSS/assets) to the browser.
If the page also includes client-side interactivity, the browser then runs a step, where client JavaScript attaches behavior (event listeners and state) to the server-rendered markup. Different frameworks implement hydration differently, but the goal is the same: make the server-rendered UI interactive on the client.
SPA
SPA, or single-page application, is an app where most UI rendering and route transitions happen in the browser after the initial page load. The app is built into optimized JavaScript/CSS assets (often multiple chunks, not just one bundle) and deployed to a web server/CDN.
Unlike classic multi-page navigation, a SPA typically updates views client-side and fetches data asynchronously from APIs as needed. Here’s how that looks:
In many SPA setups, the server initially returns a lightweight HTML shell containing a mount point. Client JavaScript then renders the UI, handles route transitions in the browser, and fetches data over HTTP when needed. This reduces full-page reloads, but API round-trips still happen for dynamic data.
For the better part of a decade, SPAs have been a go-to for highly interactive apps. At the same time, SSR has stayed popular for content-heavy routes and SEO-sensitive pages, while SSG remains a strong choice for content that changes infrequently.
In practice, many modern frameworks are hybrid and let you mix SSG, SSR, and client-rendered patterns per route.
Like most technologies, each option has its tradeoffs, and I recommend doing a deeper dive into how they work. I have some great resources linked under my bookmarks section if you’re curious.