Jamstack in 2026: What Survived and What Replaced It

Jamstack is no longer a label anyone puts on a slide deck, but it did not lose: it became the baseline. Pre-rendered HTML, CDN-first delivery, APIs behind the page and deploys triggered by git are now what every major web framework does by default. What replaced the term is hybrid rendering, where a single project mixes static generation, incremental regeneration, server rendering and edge functions per route. This guide explains what Jamstack meant, what survived, how the rendering strategies compare in 2026, and how to decide whether your next site should be static, hybrid or a classic server-rendered app.

What Jamstack meant and why the term faded

The acronym stood for JavaScript, APIs and Markup. The idea, pushed by Netlify around 2016, was simple: build the whole site ahead of time, push the files to a CDN, and use client-side JavaScript to call APIs for anything dynamic. No origin server to patch, nothing to scale, and every deploy is an immutable snapshot you can roll back by pointing at a previous build.

Three things made the label obsolete. The "no server" promise broke on contact with real products: sites needed personalization, editor previews and content that changed faster than a build could run, so frameworks added Incremental Static Regeneration and server rendering inside the same project. Edge runtimes then made a function running near the user in milliseconds close enough to "static" that the old split lost meaning. And the vendors moved on: the frameworks now market "hybrid rendering", "server components" and "islands". The practices are everywhere; the brand is gone.

What survived, and what you should still insist on:

• Pre-render whatever can be pre-rendered. Marketing pages, docs, blog posts and product listings do not change per visitor.
• Serve from the edge by default. The CDN is the first hop, the origin is the exception.
• Decouple content and data behind APIs. Content lives in a headless CMS or in git; the site is a consumer.
• Deploy from git with immutable, previewable builds. Every pull request gets a URL, every deploy can be rolled back.

Rendering strategies compared

Modern frameworks let you choose per route. The table summarizes the options as they behave in 2026.

Strategy	Freshness	TTFB	Hosting cost	Complexity	SEO	Best for
SSG (static generation)	Rebuild required	Lowest, CDN hit	Lowest, files only	Low	Excellent, full HTML	Marketing, docs, blogs, small catalogs
ISR (incremental static regeneration)	Seconds to minutes, background refresh	Low, CDN hit; first miss is slower	Low; needs a platform that supports it	Medium, cache invalidation to reason about	Excellent	Large catalogs, news, CMS-driven sites with many pages
SSR (server-side rendering)	Every request	Higher, origin or region round trip	Highest, compute per request	Medium to high	Excellent	Personalized pages, search results, logged-in views
CSR (client-side rendering)	Every request, after JS loads	Low for the shell, slow for content	Low	Low	Weak; crawlers see an empty shell first	Dashboards, internal tools, apps behind login
Edge rendering	Every request	Low, runs near the user	Per-invocation, usually cheap at low volume	Medium; limited runtime APIs	Excellent	Geo and A/B logic, auth checks, light personalization on static pages
Islands (partial hydration)	Static shell, live islands	Lowest for the page	Lowest	Low to medium	Excellent	Content sites with a few interactive widgets

One note: TTFB is about the first byte, not the full page. A CSR shell arrives fast and then does nothing useful until the bundle runs and fetches data, which is why it scores badly on Core Web Vitals.

In practice a 2026 site combines several of these. A typical setup: SSG for content, ISR for the product catalog, an edge function for the cookie banner and locale redirect, one or two islands for search and a pricing calculator, and SSR only for the account area.

Frameworks: Astro, Next.js, Nuxt, SvelteKit, Eleventy

All five produce pre-rendered HTML and all five can deploy to a CDN. They differ in how much JavaScript ships by default and how much of the hybrid spectrum they cover.

Astro is the clearest heir to the Jamstack idea. Pages ship zero JavaScript unless you mark a component as an island, and you can write islands in React, Vue, Svelte or Solid inside the same project. It supports SSR and on-demand rendering per route through adapters, so a content site can grow an account area without changing framework. For content-heavy sites it is the default recommendation today.

Next.js covers the widest range: static export, ISR, SSR, server components, route handlers and edge runtime. The cost is complexity. The App Router with server components is a different mental model from the older Pages Router, and a fully static export (output: 'export') disables ISR, middleware and API routes, which teams discover late. This blog runs on exactly that mode, exported to Cloudflare Pages.

Nuxt gives the Vue ecosystem the same hybrid model, with route rules that declare per-path whether a page is prerendered, cached with a stale-while-revalidate window, or rendered on request:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/blog/**': { prerender: true },
    '/products/**': { swr: 600 },
    '/account/**': { ssr: false }
  }
})

SvelteKit compiles components to small runtime code, which keeps bundles light, and offers prerender, SSR and CSR flags per route plus adapters for every major host. Good fit for teams that want a full-stack framework without the React ecosystem weight.

Eleventy is the purist option: a fast static generator with no opinion about client JavaScript, right when the site is genuinely static.

Hugo and Jekyll still exist and still build quickly, but they are outside the hybrid conversation; we compare them in the static site generators guide. Gatsby, once the poster child of Jamstack, is effectively in maintenance and should not be chosen for new projects. Whatever framework you pick, the bundler underneath is now almost always Vite or the framework's own Turbopack; the trade-offs are in our build tools comparison.

Headless CMS and content workflows

Decoupling content is the part of Jamstack that aged best. The pattern has two variants.

Git-based content. Markdown or MDX in the repository, with frontmatter for metadata. Editors work through a git-backed editor (Decap, Tina, Keystatic) or directly in pull requests. Every content change is versioned, reviewable and deployed like code. This works well for docs, engineering blogs and small marketing teams, and it has zero vendor dependency. It breaks down when non-technical editors outnumber developers, when you need scheduled publishing and workflows, or when the same content feeds several channels.

API-based headless CMS. Sanity, Contentful, Storyblok, Payload, Strapi and Directus expose content over REST or GraphQL. The build (or an ISR revalidation) pulls content, and a webhook from the CMS triggers a rebuild or an on-demand revalidation of the affected paths:

// app/api/revalidate/route.ts (Next.js, deployed on a platform with ISR)
import { revalidatePath } from 'next/cache'

export async function POST(req: Request) {
  const { slug, secret } = await req.json()
  if (secret !== process.env.REVALIDATE_SECRET) {
    return new Response('Forbidden', { status: 403 })
  }
  revalidatePath(`/blog/${slug}/`)
  return Response.json({ revalidated: true })
}

Three workflow questions decide whether the setup will hold up:

1. Preview. Editors need to see unpublished content in the real layout. That requires either a preview deploy per content branch (git-based) or a draft mode in the framework that fetches unpublished entries from the CMS (API-based). Decide this before choosing the CMS.
2. Build time at scale. A few hundred pages build in under a minute. Tens of thousands do not. Past that point you need ISR or on-demand rendering for the long tail, and a CMS that can deliver only the changed entries.
3. Content modeling. Model content as structured fields, not as HTML blobs. The site is one consumer; a mobile app, a newsletter or an AI assistant will want the same content later.

For the full comparison of headless versus traditional CMS, see headless CMS vs traditional CMS.

Hosting: Cloudflare Pages and Workers, Vercel, Netlify

Serving static files is a commodity; the platforms compete on the dynamic layer and on the developer workflow around it.

	Cloudflare Pages / Workers	Vercel	Netlify
Pricing model	Generous free tier; paid plans priced by requests and Workers usage, no bandwidth charges	Free hobby tier; Pro per seat plus usage (bandwidth, function invocations, image optimization)	Free tier; paid per seat plus bandwidth and function usage
Edge runtime	Workers everywhere, V8 isolates, one runtime model	Edge runtime for middleware and selected routes; Node functions in regions	Edge Functions on Deno; Node functions in regions
Storage primitives	KV, R2 (S3-compatible), D1 (SQLite), Durable Objects, Queues	KV, Blob, Postgres via partners	Blobs, plus partner integrations
Framework fit	Framework-agnostic; Next.js works via an adapter, not first-party	Next.js first-party; other frameworks supported	Framework-agnostic; strong Astro and Eleventy support
Lock-in surface	Workers APIs, bindings to KV/R2/D1	ISR, image optimization, middleware behavior tied to Vercel's build output	Netlify Functions, Forms, Identity
Where it fits	Cost-sensitive high traffic, global edge logic, teams comfortable with the Workers model	Next.js teams that want zero configuration and pay for it	Teams that value the integrated forms, identity and plugin ecosystem

The honest framing on lock-in: the static output is portable on all three. Move a plain Astro or Eleventy site between them in an afternoon. What does not move is everything that touches the platform runtime: ISR semantics, edge middleware, KV reads, image endpoints, form handlers. Keep those behind thin adapters in your own code, and keep the count small, and migration stays a day of work rather than a quarter.

Forms, auth and search on a static site

These three are where teams historically concluded "we need a real backend." In 2026 each has a standard pattern.

Forms. Post to a function or a hosted endpoint. Netlify Forms and Cloudflare Workers handle the submission; for a marketing site a hosted form provider (this blog uses Brevo embeds) is enough. Validate in the browser for feedback and in the function for trust, and add a honeypot and rate limiting.

Authentication. Never validate credentials in the browser. Use a hosted identity provider (Auth0, Clerk, Supabase Auth, Cloudflare Access for internal sites) and check the session token in an edge function before serving protected HTML, or render the protected area with SSR. The patterns are in modern authentication with OAuth 2.0, JWT and zero trust.

// Cloudflare Pages Function: functions/account/_middleware.js
export async function onRequest({ request, next, env }) {
  const token = request.headers.get('Cookie')?.match(/session=([^;]+)/)?.[1]
  if (!token || !(await verify(token, env.JWT_SECRET))) {
    return Response.redirect(new URL('/login/', request.url), 302)
  }
  return next()
}

Search. Two options. For up to a few thousand pages, build a search index at build time (Pagefind is the reference tool here) and let the browser query it; no backend, no cost, works offline. For larger or faceted catalogs, call a hosted search API (Algolia, Meilisearch, Typesense) from an island. Either way the pages stay static.

The same approach extends to comments, carts and newsletters: the HTML is static, the interaction is an API call, and secrets live in a function, never in the client bundle.

When a traditional server-rendered app is the better choice

Pre-rendering is not free. It adds a build pipeline, a cache invalidation model and a second place where bugs can hide (the build) alongside runtime. Choose a classic server-rendered application (Laravel, Rails, Django, ASP.NET, Spring, or Next.js in full SSR mode on a server you run) when:

• Most pages are per-user. A SaaS dashboard, a banking portal, an internal ERP. There is nothing to pre-render; the framework would just be a slower way to write a server.
• Data changes faster than any revalidation window. Live inventory, trading, real-time collaboration. Pre-rendering becomes a cache you constantly fight.
• The team runs a backend framework well. A team fluent in Laravel or Django ships faster with server-rendered templates plus a sprinkle of client JavaScript than by learning a hybrid framework's caching semantics.
• You need transactions in the request path. Checkout, booking, payments. Serverless functions can do it, but the transaction and observability tooling of a monolith is more mature.
• Compliance requires a single, auditable origin. Some regulated environments want all requests logged in one place and no third-party edge runtime in the path.

The two common failure modes are mirror images: a content site built as a client-rendered SPA and then retrofitted with SSR for SEO, and a dashboard built as a static site with dozens of functions, recreating a backend one endpoint at a time.

Decision checklist

Answer these before choosing a rendering model.

• What share of pages is identical for every visitor? Above roughly three quarters, start from SSG or islands.
• How often does content change, and can a build or a revalidation keep up? Hourly is fine for ISR; per second is SSR territory.
• How many pages will exist in two years? Past tens of thousands, plan for ISR or on-demand rendering from day one.
• Who edits content, and do they need previews and scheduling? Non-technical editors push you toward an API-based CMS with draft mode.
• Which dynamic features are required: forms, auth, search, cart, comments? List them and map each to a function, a hosted service or an island.
• Does SEO matter for these pages? If yes, CSR is out; everything else is fine.
• What is the team fluent in? Framework fit beats benchmark charts.
• How much platform-specific runtime are you willing to take on? Count the ISR, edge and storage features you plan to use; each one is lock-in.
• What is the monthly budget at ten times current traffic? Static on a CDN stays flat; per-request compute does not.
• Is there a hard compliance reason to keep a single origin? If yes, server-rendered on infrastructure you control.

Recommendation

Stop asking whether to "do Jamstack." Ask, per route, where the HTML should be produced. For marketing sites, documentation, blogs and catalogs up to a few thousand pages, build static with Astro or Eleventy, deploy to Cloudflare Pages or Netlify, and add forms, search and auth through functions and hosted services; you will get the best performance and the lowest bill with almost no lock-in. For larger content sites and e-commerce, use a hybrid framework (Next.js, Nuxt, Astro with SSR) with ISR for the catalog and edge functions for personalization, and keep platform-specific features behind thin adapters. For applications that are mostly logged-in and per-user, build a server-rendered app on the stack your team already runs, and pre-render only the public pages. At Arvucore we usually recommend starting from the static end of the spectrum and adding server rendering route by route, because it is far easier to make a static page dynamic than to make a dynamic app fast.