What is JAMstack?

Where the term came from

The phrase was coined by Mathias Biilmann, co-founder of Netlify, around 2015. The original observation was that the LAMP stack (Linux, Apache, MySQL, PHP) was overkill for content sites — you did not need a server executing code on every page view if the page never changed between deploys. Pre-render the HTML once, serve it from a CDN, and only call backend services when you actually need fresh data.

For about five years, JAMstack was a strong rallying cry — it produced Gatsby, Hugo, Eleventy, and a generation of CMS-driven marketing sites that loaded instantly and never went down. By 2022 the lines blurred: frameworks like Next.js, Remix, and Astro absorbed the ideas while adding server-side rendering and edge runtime, and "JAMstack" as a distinct label faded.

What the three letters mean

JavaScript handles interactivity in the browser — forms, animations, anything that responds to user input. APIs provide everything dynamic — product data, prices, user accounts, search — accessed at request time from third-party or first-party services. Markup is the pre-rendered HTML, generated at build time and served straight from a CDN, with zero server-side computation needed for the page itself.

The build, deploy, edge model

JAMstack-era thinking introduced a workflow most modern hosts still use: source code lives in Git, a push triggers a build, the build outputs static assets and serverless functions, and the result is pushed to a global CDN. The deploy artifact is the output, not the source. Rollbacks are instant because the previous build is still on the CDN. Preview branches get their own URL automatically. This is the operational model Vercel, Netlify, and Cloudflare Pages all converged on, and it outlived the JAMstack label.

Where it wins and where it does not

JAMstack wins for content sites, documentation, marketing pages, e-commerce catalogs that change at most a few times a day, and anything where global performance matters more than per-user personalization. It struggles when every page needs fresh, personalized data — at that point you are calling APIs on every request anyway, which negates much of the speed advantage.

Modern frameworks resolve this by letting you choose per page or per component: static where it makes sense, server-rendered where you need personalization, client-rendered for the truly interactive bits.

At QUANT LAB

We build on Next.js on Vercel, which is a direct descendant of the JAMstack architecture. Marketing pages are statically generated, dashboards use server-side rendering, and dynamic data comes from typed APIs. Our web application development engagements default to this pattern.

Headless CMS as the back end

JAMstack popularized the headless CMS pattern — products like Contentful, Sanity, Strapi, Storyblok, and Payload store content and expose it through APIs, while the front-end framework renders it. The editorial team gets a nice authoring UI; the engineering team gets pre-rendered pages and fast queries. Compared to monolithic WordPress or Drupal, headless decouples content from presentation and lets a single content base drive a website, mobile app, and email program from one source.