Jamstack didn't die. It won so hard nobody says the word anymore.
Netlify pulled "Jamstack" off its own homepage in October 2023. The community Discord closed. The State of Jamstack survey, running since 2020, ended. Easy read: the architecture failed. Wrong read. Pre-rendering, API-
Netlify pulled "Jamstack" off its own homepage in October 2023. The community Discord closed. The State of Jamstack survey, running since 2020, ended.
Easy read: the architecture failed.
Wrong read. Pre-rendering, API-first content, edge delivery, decoupled front ends — those all ship as defaults now in Next.js, Astro, Nuxt, and SvelteKit. Nobody needs a name for the normal thing.
The part that actually changed
The original Jamstack answer to dynamic content was "fetch it in the browser after load." That still works for a view counter. It ages badly everywhere else — client fetches hurt LCP, and crawlers see an empty slot.
So the current shape is three tiers, not two:
| Tier | Runs at | Good for |
|---|---|---|
| Pre-rendered | Build time | Posts, docs, marketing pages |
| On-demand render | Request time | Search results, per-user pages |
| Client fetch | After load | Counters, badges, live widgets |
Put each piece of content in the cheapest tier that meets its freshness need. That one rule replaces most 2019-era Jamstack advice.
What it means when you pick tools
Stop filtering on the label. Judge the traits:
- Does it pre-render?
- Does it serve from an edge?
- Does content arrive over an API?
Same test applies to your CMS, and it rules out more of them than you'd expect. A build step can't call a browser-only SDK. Three things to check:
- A plain HTTP API with a server-side key
- Webhooks on publish, so builds trigger themselves
- A portable content format, not a vendor-specific tree
That last one is the expensive one to get wrong. A proprietary rich-text tree means writing a converter, then rewriting it when the front end changes.
The full write-up covers how a page moves through the whole chain, why Netlify moved to "composable," and the arithmetic for deciding if static fits at all:
Static Site Architecture and the Jamstack, Explained →
We build Draftbase, a headless CMS that stores rich text as plain MDX and serves it over cached REST and GraphQL. Hobby is free, and easy to start with our templates.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.