All posts
Engineering··2 min read

Jamstack, headless, and the return of the server

A look back at 2021, when static sites and headless CMSs were the answer to everything — what they got right, and why the server came back.

Numan HussainNuman HussainEntrepreneur · Developer · Team Lead
Jamstack, headless, and the return of the server

A look back, written in 2026. By 2021 “Jamstack” had become shorthand for a way of building sites: generate the pages ahead of time, serve them from a CDN, and pull content from a headless CMS through an API. For a while it was the answer to every question.

What it got right

Speed and safety. A pre-built page served from the edge is about as fast as the web gets, and a site with no server to attack is very hard to break into. For marketing sites that change weekly rather than by the minute, that is a sensible trade.

It also separated content from presentation properly. Editors wrote in a CMS designed for writing; developers built the site in whatever they liked. Neither could break the other's work.

Where it struggled

Build times. A site with a few thousand pages could take many minutes to rebuild, and every typo fix waited for the whole thing. Incremental builds eased it, but the mental model — “the site is a snapshot” — kept fighting anything that needed to be current.

Anything dynamic. Search, forms, logged-in areas, prices that change: each one needed a separate service, a serverless function, or a third-party widget. A simple site could end up depending on six vendors, each with its own bill and its own outage.

And editors. A headless CMS shows content as fields, not pages. Clients used to seeing their page as they edited it often found it abstract, and previewing a change before publishing took real work to set up.

Before choosing a headless setup, ask who edits the site and how often. If the answer is “a busy partner, twice a year”, the editing experience matters more than the architecture.

The server came back

The frameworks answered by blurring the line. Next.js 12, in October 2021, pushed rendering towards the edge; Remix went open source that November built around the server; and within a year or two the leading frameworks let each page choose — pre-built, rendered on request, or cached and refreshed in the background.

That is roughly where sensible practice sits now. Static where content is stable, server-rendered where it needs to be current, and one codebase deciding page by page rather than a whole architecture committed up front.

What I took from it

Choose the simplest thing that meets the editor's needs and the visitor's. Sometimes that is a static site. Sometimes it is a well-run CMS. The mistake of 2021 was treating one of those as a belief rather than a decision.

Keep reading