Opinion
What's left of the JAMstack
JAMstack is dead.
What the word meant
JAMstack stood for JavaScript, APIs and Markup. Netlify's founders coined it around 2016. The proposal was concrete: pre-render a site to static files, serve those files from a CDN, and use browser JavaScript and third-party APIs for anything dynamic.
Gatsby, Hugo, Jekyll, Eleventy and early Next.js static export belonged in that picture. Netlify and Vercel built businesses on it. Content came from Markdown files in the repository or from an API, and the API side is where headless CMSs grew up.
What it got right
Static files are fast, cheap and hard to hack. A CDN is a better front door than a PHP box. Those remain good reasons to build a site this way.
The build also gave you a reproducible artifact. You could pin it and roll it back. I put more value on that property than on whether a framework still fits an old acronym.
A build is a reproducible artifact.
The content API mattered just as much. Content could be the source for the site without being a database joined to templates.
Choosing an API for content does not settle whether every page should be static. It gives you a source to work from. Content delivery and page rendering are separate decisions.
How it went wrong
Build times grew with content. A ten-thousand-page site rebuilding for a typo is a concrete problem, whatever you call the architecture. A tidy deployment model doesn't excuse that cost.
Every dynamic need became a function or a client-side fetch. Incremental regeneration and on-demand rendering were bolted on. Those additions made the original definition less useful as a guide to what a site actually does.
By now, every major framework renders on the server again. Next.js has the app router, Astro has server islands and on-demand pages, and SvelteKit and React Router (formerly Remix) are part of that server-rendered picture. Netlify itself stopped leading with the word JAMstack.
The term is dead; the useful parts have become standard practice. Describe which pages are built ahead of time, which need server rendering, and where their content comes from. That tells me more than the label does.
What's left
Keep the build as an artifact you can pin and roll back. Keep static output wherever content changes slower than requests arrive. A long build is a reason to examine the build, not to discard static files everywhere else.
Keep a content API as the source. I don't want the choice of templates to dictate where content lives. That preference doesn't mean every site needs a headless CMS.
Rebuilding on publish is the other part worth keeping, with one correction. Publication is the point at which the content changes for readers, so that is the moment to produce pages. That part the old pattern got right.
What it got wrong was the scope. A typo rebuilt the whole site, and that is what people walked away from. That part is fixable now. Astro can restore every page whose content and code did not change and render only the rest, and a cached server-rendered site, like Next.js with cache tags, can expire just the pages a publish touched.
The dynamic parts can still be dynamic. Another part needing server rendering is no reason to abandon static output for content that suits it. Make that decision around the content and the request.
Where Shapio fits
Shapio is built for the parts of this that held up. A build pins one publication snapshot (?snapshot=N), so every page in it shows the same moment of content and schema. With a deployment connection, a publish fires the deploy hook and Shapio follows the build until it finishes. The site you are reading is built that way.
The scope problem is handled in the starters. The Astro starter keys every page on the content it renders, so a publish re-renders the pages that changed and restores the rest from the previous build, as long as the host keeps its build cache. The Next.js starter caches its reads by tag, and a publish expires only the tags of the content that changed.
The CMS itself never needs a deploy. Content types are data in the database: change one in the admin and the REST and GraphQL APIs serve the new field on the next request. Showing that field on the site is a change to the site's code, which ships with the site's next deploy.
For the parts that must be dynamic, the same content is on the API, and in a Next.js app @shapio/local serves it in-process. Build the static pages on publish, and render on request only what needs it.