Jamstack Was Never About Static Sites

Jamstack Was Never About Static Sites

When Jamstack started gaining traction, the conversation was dominated by performance.

Lighthouse scores. Time to first byte. Core Web Vitals before Core Web Vitals were a thing. Developers would post before-and-after charts showing monolithic server-rendered sites at 4 seconds and Jamstack rebuilds at 800 milliseconds. The marketing was all speed.

That framing helped sell the idea. It also obscured what actually mattered.

Jamstack did not win because of fast page loads. It won because it separated concerns that had been tangled together for twenty years: frontend from backend, content from presentation, deployment from infrastructure. The performance was a side effect of getting the architecture right. Teams that only noticed the performance missed the more durable insight.

What Jamstack was actually about

Matt Biilmann coined the term in 2015 and presented it publicly at SmashingConf San Francisco in 2016. The acronym, JavaScript, APIs, and Markup, was a handle for a principle: decouple the web experience layer from data and business logic.

The label described three separations that had quietly become possible at the same time.

Frontend from backend. The rise of modern JavaScript meant complex, dynamic interfaces could run entirely in the browser. The frontend no longer needed to be tightly coupled to a server generating HTML on every request. It could talk to the backend through well-defined APIs, independently deployed and independently scaled.

Content from presentation. The API economy created a market of specialised services: headless CMSs for managing content, commerce APIs for handling transactions, search-as-a-service, authentication-as-a-service. You no longer had to own the full stack. You could compose the right tool for each concern and let each evolve independently.

Deployment from infrastructure. Static site generators and build pipelines meant a site could be pre-built at deploy time and served from a CDN edge, with no server in the request path. Deployment became a build operation, not a server operation.

These three separations are why Jamstack compounded. Each layer could change without breaking the others. Frontend teams iterated independently. Content editors worked without touching code. Deployments became low-risk because the surface area of each release was narrow.

The term won so much it became invisible

Biilmann put it plainly: "Jamstack won so much that it became less useful as a community term, since basically all modern web frameworks ended up being built around self-standing frontends talking to APIs and services."

Netlify eventually shut down the Jamstack Community Discord. The term faded from their marketing. Not because the idea failed, but because it succeeded completely. The principles became so standard that naming them felt redundant, in the same way nobody says "responsive web design" any more. They just design for screens.

Today the successor term is "composable web" or "composable architecture." It extends the same logic: build from specialised, interchangeable layers rather than from monoliths. The vocabulary changed. The architectural principle is the same one Biilmann drew on stage in 2016.

What the case studies actually show

The companies that migrated to Jamstack and reported dramatic improvements were not just seeing better Lighthouse scores. They were seeing what architectural separation does to a team's ability to move.

ButcherBox, the US meat delivery company, moved from a WordPress and PHP monolith to Netlify, Gatsby, and Contentful. Load time dropped from 4–7 seconds to under one second. But the operational story was equally significant: their head of engineering had an initial site running in about an hour, because the layers were composable rather than entangled.

Manscaped was fully on a Shopify theme until 2019. When they expanded into international markets, the monolithic model broke down: copying and pasting theme files to support multiple regions compounded errors and made minor updates painful. They migrated to a headless Jamstack setup. The architecture problem was never performance. It was that a monolith cannot cleanly support parallel teams working on parallel concerns.

Klépierre, a large European retailer, migrated from monolithic Sitecore to a headless architecture on the Jamstack with the agency Proximity. They launched 98 new regional properties in six months. That velocity did not come from a faster CDN. It came from content, infrastructure, and frontend being genuinely independent.

The lesson that still gets missed

Most teams evaluating their architecture focus on the performance question. Does this approach make the site faster? Sometimes that is the right question. More often, the deeper question is whether the architecture makes the team faster.

Monolithic architectures are slow not because servers are slow. They are slow because coupling between layers creates coordination costs. Changing content requires a developer. Changing a frontend component risks breaking a backend integration. Deploying a small fix requires testing the entire system. The speed problem in a monolith is usually a people and process problem embedded in the architecture.

Jamstack, and its successor composable patterns, addresses the structural cause rather than the symptoms. When layers are genuinely independent, teams can work independently. That compounds over time in ways that a performance optimisation does not.

This mirrors what we see with deployment workflows more broadly: the bottleneck is rarely the technology, it is the coupling between systems. This is why headless WordPress is now mainstream, not fringe. WordPress powers around 43% of the web, but major brands including TechCrunch and Beachbody have decoupled the frontend entirely and use WordPress as a content API with a separate presentation layer. The CMS was not the problem. The coupling was.

Where this leaves teams today

The vocabulary debate around Jamstack is largely irrelevant. Whether your team calls the approach Jamstack, headless, composable, or just how they build now does not matter. What matters is whether the separations are real.

Can the frontend team deploy without coordinating with the backend? Can content editors publish without involving engineering? Can the infrastructure layer change without breaking the presentation layer?

If the answer to any of these is no, the coupling is still there, regardless of the label.

The practical question is not which framework to use. It is which contracts to establish between layers, and whether those contracts are clean enough that each layer can be maintained, replaced, and deployed on its own schedule.

Forge's POV: deployment is a layer, not a system

The same logic that applies to frontend and backend applies to deployment and infrastructure.

When deployment is entangled with hosting infrastructure, it becomes a ceremony. Teams coordinate releases. Environments are contested. Changes queue behind whoever manages the servers.

Forge's developer platform is built around the principle that deployment should be its own clean layer: git-driven, branch-aware, and independent of the content or application layers it serves. The goal is for the deployment concern to be genuinely separate from everything else, so changing how you deploy does not require changing how you build or how you manage content.

That is the Jamstack insight applied to the hosting layer. The name has changed. The principle has not.

Static sites were never the point. The point was always separation of concerns. The teams that understood that have kept compounding, regardless of which term came into fashion next.