Ik bouw Jamstack-sites sinds 2018. Destijds was de pitch onweerstaanbaar: pre-render alles naar statische HTML, serveer het via een CDN, en voeg API's toe voor dynamische functies. Het was snel, veilig en goedkoop om te hosten. Netlify bedacht de term, Gatsby reed op de hype-golf, en voor een tijdje voelde het als de toekomst van webontwikkeling.

Nu is het 2026, en het gesprek is dramatisch verschoven. De Jamstack Discord-servers zijn stiller. Gatsby is effectief dood. Netlify heeft een significant deel van haar personeelsbestand afgebouwd. En toch — en dit is het onderdeel dat mensen missen — de ideeën achter Jamstack zijn overal. Ze dragen alleen niet meer dat label.

Is Jamstack dus dood? Het eerlijke antwoord is ingewikkeld, en ik denk dat de nuance belangrijker is dan de warme uitspraak.

Inhoudsopgave

Is Jamstack Dead in 2026? An Honest Assessment of What Changed

Wat Jamstack Eigenlijk Betekende

Laten we preciës zijn over definities, want veel van de 'Jamstack is dood'-discourse lijdt aan het feit dat mensen het over verschillende dingen hebben.

De originele Jamstack (JavaScript, APIs, Markup) had een paar kernprincipes:

  1. Pre-rendering: HTML genereren bij build-tijd, niet bij request-tijd
  2. Decoupling: Scheiding van je frontend van je backend/CMS
  3. CDN-first: Serveer alles vanaf de edge
  4. API-driven: Handel dynamische functionaliteit af via API's en serverless functies

De kernfilosofische inzet was dat build-tijd beter is dan request-tijd. Je doet het zware werk eenmaal tijdens implementatie, en elke bezoeker krijgt het gecachede resultaat.

Dit werkte briljant voor blogs, marketingsites, documentatie en e-commerce productpagina's. Het werkte verschrikkelijk voor alles wat personalisatie nodig had, real-time data, of inhoud die elke paar minuten veranderde.

De Tijdlijn van Achteruitgang

Hier is ruwweg hoe het Jamstack-narratief uiteenviel:

Jaar Gebeurtenis Impact
2020 Gatsby haalt $28M Series C op Piek Jamstack-hype
2021 Next.js introduceert ISR (Incremental Static Regeneration) Vervaagt grens tussen statisch en dynamisch
2022 React Server Components aangekondigd Paradigmaverschuiving naar server rendering
2023 Next.js App Router wordt stabiel, Gatsby-gebruik duikt ineen Hybrid rendering wordt standaard
2023 Netlify neemt Gatsby over, stopt het vervolgens Symbolisch einde van 'pure' Jamstack
2024 Astro 4.x krijgt veel aandacht, Vercel zet in op PPR Statische generatie leeft voort in nieuwe vormen
2025 Next.js 15 geleverd met volwassen RSC-patronen Server-first wordt mainstream-standaard
2026 De term 'Jamstack' komt zelden voor in vacatures of RFP's Het merk is dood, de principes blijven bestaan

Het Gatsby-verhaal is bijzonder illustratief. Op zijn hoogtepunt had Gatsby duizenden plugins, een enorme gemeenschap, en echte enterprise-adoptie. Tegen 2024 was het aantal npm-downloads met meer dan 80% gedaald van het piek. Netlify's overname redde het niet — het was meer een acqui-hire die stilletjes werd afgebouwd.

Maar Gatsby's achteruitgang wijten aan 'Jamstack sterft' mist het punt. Gatsby achteruitgang omdat het echte technische problemen had: belachelijk lange build-tijden, een ingewikkelde data-laag (GraphQL voor alles, of je het wilde of niet), en een plugin-ecosysteem dat een aansprakelijkheid werd. Next.js at Gatsby's lunch niet omdat statische generatie fout was, maar omdat Next.js het beter deed en meer flexibiliteit bood.

Waar Jamstack Won (Permanent)

Hier is wat ik denk dat mensen verkeerd begrijpen over het 'Jamstack is dood'-narratief: de kernideeën wonnen zo volledig dat we stopten het op te merken.

Ontkoppelde Architectuur is de Standaard

De grootste Jamstack-overwinning is dat ontkoppelde frontends nu de norm zijn voor elk serieus webproject. In 2018 moest je argumenteren voor het scheiden van je frontend van WordPress of je CMS. In 2026 is de vraag niet 'zouden we ontkoppeld moeten zijn?' — het is 'welke headless CMS en welk frontend-framework?'

Dit is een permanente architecturele verschuiving. Niemand gaat terug naar monolithische PHP-templates voor nieuwe projecten (legacy-onderhoud is een ander verhaal). Het headless-patroon — of je het nu Jamstack noemt of niet — won.

We zien dit voortdurend in ons headless CMS-ontwikkelingwerk. Klanten vragen niet meer 'zouden we headless moeten gaan?' Ze vragen welke headless CMS in hun content-model past.

CDN-First Delivery

Elk belangrijk framework en hosting-platform geeft nu prioriteit aan edge-levering. Vercel, Cloudflare, Netlify, AWS — ze gaan allemaal ervan uit dat je inhoud zo dicht mogelijk bij de gebruiker zou moeten zijn. Dit was een Jamstack-principe voordat het een industry-standaard werd.

Git-Based Workflows

Het idee dat je site van een git-push af inzet, door CI/CD gaat, en op een preview-URL terechtkomt voordat het productie raakt? Dat was radicaal in 2017. Het is nu standaard. Elk frontend-platform biedt dit aan. Jamstack normaliseerde het.

Static Generation als Hulpmiddel (Niet als Religie)

SSG is niet doodgegaan. Het werd één hulpmiddel onder velen. Elk belangrijk framework — Next.js, Astro, Nuxt, SvelteKit — ondersteunt statische generatie. Het verschil is dat het nu een per-pagina-keuze is in plaats van een architectuur waarbij je alles of niets kiest.

Is Jamstack Dead in 2026? An Honest Assessment of What Changed - architecture

Waar Jamstack Verloor

Eerlijk zijn betekent ook de echte mislukkingen erkennen.

Build-Tijden waren een Echt Probleem

Het vuile geheim van grote Jamstack-sites waren build-tijden. Ik werkte in 2021 aan een project met 40.000 productpagina's. Volledige rebuild? 45 minuten. Zelfs met incrementele builds betekende elke schema-wijziging opnieuw beginnen. Wanneer je content editors 20 minuten moeten wachten om een wijziging op de live-site te zien, heb je het argument over developer experience verloren.

ISR en on-demand revalidatie in Next.js waren directe reacties op dit probleem. Ze erkenden dat het pre-renderen van alles bij build-tijd niet verder schaal dan een bepaald punt.

Personalisatie was altijd een Hack

Jamstack-sites zijn geweldig wanneer iedereen dezelfde inhoud ziet. Op het moment dat je gebruiker-specifieke inhoud nodig hebt — aangemelde toestanden, gepersonaliseerde aanbevelingen, A/B-tests, geo-doelgerichte prijzen — ben je tegen de architectuur aan het strijden. Client-side fetching creëert layout shift. Edge middleware voegt complexiteit toe. Je eindigt met het bouwen van een server-gerendereerde app met extra stappen.

De 'J' in Jamstack werd Opgeblazen

JavaScript bundel-maten op Jamstack-sites werden uit de hand. Gatsby-sites leverden routinematig 300-500KB JavaScript op voor wat in wezen een blog was. De statische HTML was snel, maar vervolgens zou de hydratatiestap het main thread seconden lang blokkeren op mobiele apparaten. Dit was een eigen doelpunt.

Astro's eiland-architectuur en server components zijn beiden opgerezen als directe reacties op dit JavaScript-opblazing probleem.

Preview en Editing Experience Leed

Content editors gewend aan WordPress's live preview hadden een moeilijke tijd met Jamstack. Je veranderde een titel in je CMS, triggerde een webhook, wachtte op een build, en zag dan misschien je wijziging. Hulpmiddelen zoals visuele editors en draft modes verbeterden dingen, maar de ervaring kwam nooit overeen met wat een traditionele CMS meteen bood.

De Opkomst van Server Components en Hybrid Rendering

React Server Components (RSC) vertegenwoordigen de grootste filosofische verschuiving in frontend-architectuur sinds het SPA-tijdperk. En ze zijn fundamenteel in tegenspraak met pure Jamstack-denken.

Hier is waarom: RSC veronderstelt dat rendering op de server bij request-tijd goed is, eigenlijk. In plaats van alles vooraf te bouwen, render je componenten op de server, stream je HTML naar de client, en stuur je nul JavaScript voor componenten die geen interactiviteit nodig hebben.

Dit draait het Jamstack-script om. In plaats van 'alles vooraf bouwen en statische bestanden serveren,' is het 'on-demand renderen maar slim zijn over wat JavaScript nodig heeft.'

De resultaten spreken voor zich. Een goed gebouwde RSC-applicatie kan de Time to First Byte van een statische site evenaren of overtreffen terwijl deze personalisatie, real-time data, en dynamische inhoud afhandelt zonder enige Jamstack-workarounds.

// Een server component in Next.js App Router — geen client-side JS verzonden
async function ProductPage({ params }: { params: { slug: string } }) {
  const product = await getProduct(params.slug);
  const reviews = await getReviews(product.id);

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      {/* Deze component draait op de server. Nul KB naar de browser. */}
      <ReviewsList reviews={reviews} />
      {/* Alleen deze interactieve component levert JavaScript */}
      <AddToCartButton productId={product.id} />
    </main>
  );
}

Het mentale model is schoner dan het Jamstack-equivalent, waar je de productpagina statisch zou genereren, vervolgens client-side reviews zou ophalen, vervolgens de winkelwagen-knop zou hydrateren, laadtoestanden voor elk afhandelen.

Next.js App Router: De Jamstack-Killer of Zijn Evolutie?

Ik zou zeggen dat het allebei is. Next.js heeft Jamstack niet gedood — het absorbeerde het.

Next.js 15 in 2025 ondersteunt elke rendering-strategie die je zou willen:

  • Static Generation (SSG): Pagina's gerenderd bij build-tijd
  • Server-Side Rendering (SSR): Pagina's gerenderd per request
  • Incremental Static Regeneration (ISR): Statische pagina's die op een schema revalideren
  • Partial Prerendering (PPR): Statische shells met server-gerendereerde dynamische gaten
  • Client-Side Rendering: Voor zuiver interactieve componenten

PPR is bijzonder interessant. Het pre-rendert een statische shell van je pagina (de indeling, navigatie, statische inhoud) en laat gaten voor dynamische inhoud die server-gerenderd en per request gestreamed wordt. Het is als Jamstack en SSR een baby kregen.

// Met PPR worden de statische delen pre-gerenderd, dynamische delen streamen in
import { Suspense } from 'react';

export default function DashboardPage() {
  return (
    <main>
      {/* Dit is pre-gerenderd bij build-tijd */}
      <h1>Your Dashboard</h1>
      <Navigation />
      
      {/* Dit streamt dynamisch in per-request */}
      <Suspense fallback={<DashboardSkeleton />}>
        <PersonalizedContent />
      </Suspense>
    </main>
  );
}

Onze Next.js-ontwikkelingspraktijk is sterk verschoven naar deze hybrid patronen. De meeste projecten gebruiken nu een mix van statische en dynamische rendering op basis per component, wat ketterij zou zijn geweest in het pure Jamstack-tijdperk.

De framework-level beslissing is verplaatst van 'statisch of dynamisch' naar 'welke rendering-strategie heeft elk stuk inhoud nodig?' Dat is een rijper gesprek.

Astro en de Static Generation Renaissance

Als je wilt beargumenteren dat Jamstack leeft, is Astro je beste bewijs.

Astro nam de beste delen van Jamstack — statische generatie, minimale JavaScript, snelheid-standaard — en bouwde een framework dat de slechte delen fixt. Zijn eiland-architectuur betekent dat je standaard nul JavaScript levert en slechts daar interactiviteit opkiest waar je het nodig hebt.

Voor content-zware sites is Astro's benadering moeilijk te verslaan:

  • Een typische Astro blog-pagina levert 0KB JavaScript op tenzij je expliciet interactieve componenten toevoegt
  • Build-tijden zijn snel omdat Astro geen volledige React-runtime bundelt
  • Content Collections bieden een type-veilige content-laag zonder GraphQL-complexiteit
  • Je kunt React, Vue, Svelte, of platte HTML-componenten gebruiken — kies je gif
---
// Dit is een Astro-component. Het draait alleen bij build-tijd.
const posts = await getCollection('blog');
---

<html>
  <body>
    <h1>Blog</h1>
    {posts.map(post => (
      <article>
        <h2><a href={`/blog/${post.slug}`}>{post.data.title}</a></h2>
        <p>{post.data.excerpt}</p>
      </article>
    ))}
    
    <!-- Alleen dit eiland levert JavaScript -->
    <SearchWidget client:load />
  </body>
</html>

Astro's server islands (geïntroduceerd in laat 2024) voegde de mogelijkheid toe om dynamische server-gerendereerde componenten binnen anderszins statische pagina's te hebben — in wezen aankomend op een vergelijkbare bestemming als Next.js PPR maar vanuit de statisch-eerste richting.

We grepen steeds vaker naar Astro in onze Astro-ontwikkelingswerkzaamheden voor marketingsites, documentatie, en content-gedreven projecten waar prestatie prioritair is en interactiviteitsbehoeften bescheiden zijn.

Functie Next.js (App Router) Astro 5.x Oude Jamstack (Gatsby)
Standaard rendering Server (RSC) Static (SSG) Static (SSG)
JavaScript verzonden Per-component Nul standaard Volledige React runtime
Build-tijden (10k pagina's) ~3-5 min ~1-2 min ~15-30 min
Dynamische inhoud Native (RSC/SSR) Server islands Client-side fetch
Personalisatie Built-in Middleware + islands Lastig op zijn best
CMS-integratie Excellent Excellent Plugin-afhankelijk
Leercurve Stijl (RSC model) Gemiddeld Gemiddeld-Hoog
Best voor Apps + content hybride Content-first sites Blogs (historisch)

De Headless CMS-Laag: Sterker dan Ooit

Hier is het ding dat me het hardst doet terugduwen tegen het 'Jamstack is dood'-narratief: de headless CMS-markt bloeit. Als de architectuur werkelijk dood was, zou zijn content-infrastructuur niet floreren.

De headless CMS-markt werd in 2024 gewaardeerd op ongeveer $2,1 miljard en zal naar verwachting $5,5 miljard bereiken tegen 2030 (verschillende analisten plaatsen de CAGR op 20-25%). Grote spelers plaatsen allemaal sterke groei:

  • Contentful blijft domineren enterprise headless CMS, met verbeterde composability-functies in 2025
  • Sanity is snel gegroeid met zijn real-time samenwerkingseditie en GROQ-querytaal
  • Storyblok sneed een sterke niche uit met zijn visuele editor, het preview-probleem oplossend dat vroeg Jamstack plaagde
  • Payload CMS (open source, zelf-gehost) krijgt serieuze aandacht van ontwikkelaars die volledige controle willen
  • Hygraph (voorheen GraphCMS) blijft GraphQL-first teams serveren

De headless CMS maakt niet uit of je frontend statische generatie, server components, of postduiven gebruikt. Het levert gestructureerde content via API's. Dat is het. De rendering-strategie is het probleem van je frontend.

Deze ontkoppeling is de meest duurzame Jamstack-erfenis. De content-laag en de presentation-laag gescheiden zijn niet een trend — het is een architectuurprincipe dat het sterven van het merk overleefde.

Hoe Moderne Architectuur er Eigenlijk uit Ziet in 2026

Dus als we het niet Jamstack noemen, hoe noemen we de manier waarop de meeste moderne sites in 2026 zijn gebouwd? Ik ben 'headless hybrid' in gesprekken gaan gebruiken, hoewel ik het niet hou. De industrie is niet tot een term gekomen, wat waarschijnlijk prima is. We hebben geen marketinglabel nodig voor goede architectuur.

Hier is hoe een typisch project er in 2026 uitziet:

Content-Laag: Een headless CMS (Sanity, Contentful, Payload, Storyblok — afhankelijk van behoeften en begroting)

Frontend-Framework: Next.js voor alles met app-achtige functies of complexe interactiviteit. Astro voor content-first sites. SvelteKit of Nuxt als het team die voorkeur heeft.

Rendering-Strategie: Gemengd. Marketingpagina's zijn statisch gegenereerd. Productpagina's gebruiken ISR of PPR. Gebruikersdashboards gebruiken server-side rendering. Interactieve widgets gebruiken client-side rendering. Het framework handelt dit allemaal af.

Hosting: Edge-first platforms. Vercel, Cloudflare Pages, Netlify, of AWS (CloudFront + Lambda@Edge) afhankelijk van schaal en begroting.

Build-Proces: Git-based CI/CD met preview-implementaties. Webhook-getriggerde revalidatie vanuit de CMS.

Als je half kijpt, ziet dit er veel uit als Jamstack met meer flexibiliteit. En dat is eigenlijk het punt.

De architecturele beslissingen die we clients helpen maken tijdens onze headless CMS-ontwikkelingsbetrokkenheid weerspiegelen deze hybrid-realiteit. Er is geen one-size-fits-all rendering-strategie. Het juiste antwoord hangt af van content-volume, personaliseringsbehoeften, editorial workflow-vereisten, en begroting. Als je deze afwegingen voor je eigen project weegt, we staan graag open voor discussie.

Veelgestelde Vragen

Is Jamstack dood in 2026? Het merk is effectief dood — je zult 'Jamstack' niet in veel vacatures of RFP's zien. Maar de kernarchitectuurprincipes (ontkoppelde frontends, CDN-levering, API-driven content, git-based workflows) zijn verspreid dan ooit. Ze zijn zo volledig opgenomen in mainstream webontwikkeling dat ze geen apart label nodig hebben. Gatsby specifiek is dood. De filosofie blijft bestaan.

Wat verving Jamstack? Hybrid rendering-frameworks zoals Next.js (met App Router en RSC), Astro, Nuxt 3, en SvelteKit hebben de pure static generation-benadering vervangen. Deze frameworks laten je per pagina, of zelfs per component, de juiste rendering-strategie kiezen — statisch, server-gerenderd, of client-side. Het headless architectuur-patroon (ontkoppelde CMS + frontend-framework + edge hosting) blijft de standaard; het draagt alleen niet langer het Jamstack-label.

Is static site generation nog relevant in 2026? Absoluut. SSG is nog steeds de beste keuze voor inhoud die niet vaak verandert en geen personalisatie nodig heeft — blogs, documentatie, marketingpagina's, landingspagina's. Astro is de go-to framework geworden voor statisch-first sites. Next.js en Nuxt ondersteunen nog steeds SSG als één rendering-optie onder velen. Wat veranderde is dat SSG nu een hulpmiddel is waar je naar grijpt wanneer passend, niet een hele architectuurfilosofie.

Wat gebeurde er met Gatsby? Gatsby werd in begin 2023 door Netlify overgenomen en is effectief gestopt. De laatste betekenisvolle update was in 2023. Het ecosysteem stortte in omdat plugin-onderhoudders verder gingen en de gemeenschap migreerde naar Next.js, Astro, en andere frameworks. Gatsby's kernproblemen — buitensporige build-tijden, geforceerde GraphQL data-laag, zware JavaScript bundles, en een complex plugin-systeem — werden nooit adequaat opgelost.

Zou ik nog steeds een headless CMS moeten gebruiken in 2026? Ja, en de markt voor headless CMS-platforms is sterker dan ooit. Contentful, Sanity, Storyblok, Payload CMS, en anderen zijn allemaal aanzienlijk volwassen geworden. Headless CMS-ontkoppeling was het meest duurzame Jamstack-principe. Het laat je je frontend onafhankelijk kiezen, content over kanalen hergebruiken, en vendor lock-in voor een monolithisch platform vermijden. Tenzij je een persoonlijk blog bouwt (waar markdown-bestanden prima zijn), is een headless CMS een waardige investering.

Hoe veranderen React Server Components de Jamstack-vergelijking? RSC verschoof fundamenteel de standaard van 'pre-render bij build-tijd' naar 'render op de server bij request-tijd.' Server components draait op de server, stuurt nul JavaScript naar de browser, en kan rechtstreeks databases en API's benaderen. Dit elimineert veel van de workarounds die Jamstack vereiste voor dynamische inhoud — geen client-side fetching meer, loading spinners, of layout shift voor data die de server in het initiële response had kunnen opnemen. RSC maakte server rendering ergonomisch aanvoelen als statische generatie.

Is Next.js App Router het migreren waard van een Jamstack-setup? Het hangt af van welke problemen je oplost. Als je huidige statische setup je behoeften afhandelt — je inhoud is vooral statisch, builds zijn snel genoeg, en je hebt geen personalisatie nodig — is er geen dringende reden om te migreren. Als je tegen build-tijden aan het strijden bent, steeds ingewikkelder client-side data-fetching toevoegt, of met preview-workflows worstelend bent, is de App Router's hybrid rendering-model waarschijnlijk de migratie-kosten waard. De leercurve voor RSC en de App Router is echt, dus reken dat in je beslissing.

Wat is het beste framework voor een nieuwe content-website in 2026? Voor zuiver content-sites (blogs, docs, marketing) is Astro moeilijk te verslaan — nul JavaScript standaard, snelle builds, excellent DX, en geweldige headless CMS-integraties. Voor sites die content met toepassingsfuncties mengen (e-commerce, gebruikersaccounts, dashboards), geeft Next.js je de meeste flexibiliteit met zijn hybrid rendering-opties. Als je team Vue prefereert, biedt Nuxt 3 vergelijkbare mogelijkheden als Next.js. Er is geen verkeerde keuze tussen deze drie; de keuze hangt af van je team's expertise en je project's specifieke behoeften.