The many definitions of Server-Side Rendering
What is a framework, even?
“Solid start to this blog post, Zach—you’re doing great.”
“Confuse them, then rescue them. This is how thought leadership works.”
Well, huh—where does Vite live?
Application frameworks typically make use of one (or more! hi Astro) component frameworks.
Now folks that spend their time in the wonderful world of frameworks have likely encountered the term “Server-Side Rendering” (often abbreviated as SSR). What they might not be familiar with is that SSR is defined differently in Component and Application framework contexts.
Component Framework SSR
A package for server-side rendering Lit templates and components.
When generating SSR code, this adds markers to
<head>elements so that hydration knows which to replace.
If "ssr", Svelte emits an object with a render method suitable for server-side rendering.
However, it is also possible to render the same components into HTML strings on the server, send them directly to the browser, and finally "hydrate" the static markup into a fully interactive app on the client.
—Vue Server-Side Rendering (SSR) Guide
Server-Side Rendering (often abbreviated as "SSR") allows you to render your application to an HTML string that can be sent to the client to improve load time.
—Preact Server-Side Rendering docs
Component frameworks define SSR as the static rendering of a component. Give it a component, get the rendered HTML back.
Application Framework SSR
Okay, fine—good so far. Seems in line with the component framework definition.
Node.js server required
A Node.js server needs to be configured to execute your Vue.js application
—NuxtJS Server side rendering
Now wait just one second. Why can’t I use a build server to server-side render the markup? The component framework definition made no mention of a Node.js (per-request) server! (Not to mention that servers often cost more than static builds.)
Also referred to as "SSR" or "Dynamic Rendering".
If a page uses Server-side Rendering, the page HTML is generated on each request.
—Next.js Server-side Rendering docs
Another definition that requires a runtime server to generate HTML (on each request!).
Server-side Rendering (SSR) is one of Gatsby’s rendering options and allows you to pre-render a page with data that is fetched when a user visits the page. While it is recommended to use Static Site Generation (SSG) or Deferred Static Generation (DSG) over SSR you might have use cases that require it…
—Gatsby’s Using Server-side Rendering (SSR) docs
Another server-based definition from Gatsby.
When you enable SSR you can: Implement sessions for login state in your app. Render data from an API called dynamically with fetch. Deploy your site to a host using an adapter.
Astro’s Server-side Rendering docs
Not explicitly stated in the Astro docs, but these are definitely runtime server features.
Application frameworks most often define SSR as the alternative to SSG (static site generation). A runtime server is used to render the components on request.
Component frameworks define SSR as generating static HTML from a component definition. They offer no preference as to whether this should or can happen at build time or at request-time.
One term, two contexts, two definitions! I do think it’s important that folks understand the distinction here—and to keep it in mind when you navigate these different contexts. My hunch is that the application framework definition will likely win out. I’ve already started referring to the component framework definition as Component SSR 😅.
SSR isn’t “free”. These SSR frameworks exist because they make a profit for their creators.
The worst outcome from this overloaded definition (in my mind) would be that folks mistakenly assume that component framework SSR requires a Node.js server! It does not. I’d hate to see ambiguity in a technical term leveraged for profit. Just know that you can use a static build to implement component SSR (maybe also known as prerendered markup) without a Node.js server, a serverless function adapter, or any of those unnecessary (and more costly) alternatives.
This post inspired by tweets from: