Je Gatsby site shipped. Voorlopig. Maar het plugin-ecosysteem rottend weg, de officiële documenten verwijzen naar gearchiveerde repo's, en je laatste beveiligingspatch kwam van een community fork. Ik heb sinds begin 2025 drie bedrijfs-Gatsby projecten naar Next.js gemigreerd — een duurde 11 dagen, een duurde 6 weken, een draait nog steeds beide parallel. Gatsby haalde $46 miljoen op, werd in 2023 overgenomen door Netlify, en werd stil afgeschaft door Q3 2025. Dit is geen framework shootout — het is een lijkschouwing van één stack en een veldgids voor degene die het overleefde. De onderstaande gegevens tonen exact waarom Next.js won, wat je migratie werkelijk zal kosten, en het ene scenario waarin je op Gatsby moet blijven.

Als je nog steeds Gatsby in productie draait, heb je een migratieplan nodig. Als je een framework voor een nieuw project kiest, is het antwoord duidelijk maar genuanceerd. Laat me je hier doorheen lopen.

Inhoudsopgave

Next.js vs Gatsby in 2026: The Complete Production Decision Guide

De staat van Gatsby in 2026

Laten we dit niet verzachten. Gatsby is, voor alle praktische doeleinden, verlaten.

Netlify verwierf Gatsby Inc. in februari 2023. De belofte was voortgezette ontwikkeling en integratie met Netlify's platform. Wat werkelijk gebeurde was een langzaam afbouwen. De laatste betekenisvolle Gatsby release (v5.13) verscheen eind 2023. De GitHub-repository heeft sinds midden 2024 minimale onderhouds-commits. Kernbijdragers vertrokken. Het plugin-ecosysteem is stagneren — veel populaire plugins zijn meer dan 18 maanden niet bijgewerkt.

Hier is de tijdlijn die belangrijk is:

Datum Gebeurtenis
Feb 2023 Netlify verwerft Gatsby Inc.
Q3 2023 Gatsby v5.13 vrijgegeven (laatste significante release)
Q1 2024 Gatsby Cloud officieel gesloten
Q2 2024 Kernteamleden verlaten Netlify
Q4 2024 npm wekelijkse downloads dalen onder 150k (van 800k+ piek)
Q1 2025 Netlify verwijdert Gatsby-specifieke docs uit primaire navigatie
2026 Geen v6 release, geen roadmap, effectief in onderhoudsmodus

De npm downloadnummers vertellen het verhaal. Op zijn hoogtepunt in 2021 haalde Gatsby meer dan 800.000 wekelijkse downloads. Per begin 2026 zit het rond de 100.000 — en het merendeel daarvan zijn bestaande CI/CD pijplijnen, geen nieuwe projecten.

Ik zeg dit niet om op Gatsby in te slaan. Het heeft het React-ecosysteem echt vooruitgeholpen. Het idee van een build-time data laag met GraphQL, beeldoptimalisatie op build-time, de plugin-architectuur — dit waren echte innovaties. Maar het framework verloor het technische argument toen Next.js ISR eind 2020 lanceerde, en het verloor het zakelijke argument toen Netlify stopte met investeren.

Als je Gatsby nu in productie draait, zijn je grootste risico's:

  • Beveiligingskwetsbaarheden in niet-onderhouden afhankelijkheden
  • Node.js versie incompatibiliteiten als het ecosysteem zich ontwikkelt
  • Plugin rot — third-party plugins breken zonder upstream fixes
  • Wervingsmoeilijkheden — ontwikkelaars willen Gatsby niet op hun cv in 2026

Next.js in 2026: Wat is werkelijk veranderd

Next.js 15 landde eind 2024, en de iteratieve releases gedurende 2025 hebben de App Router gevestigd als het primaire ontwikkelingsmodel. Hier is waar dingen staan:

React Server Components (RSC) zijn nu de standaard. Wanneer je een component maakt in de App Router, is het een Server Component tenzij je expliciet 'use client' toevoegt. Dit was niet alleen een syntaxiswijziging — het veranderde fundamenteel hoe we over data fetching en component-architectuur denken.

Partial Prerendering (PPR) ging stabiel in Next.js 15.1. Dit is de feature die Gatsby zelfs zou hebben gedood als Gatsby nog actief werd ontwikkeld. PPR laat je een statische shell onmiddellijk serveren terwijl je dynamische inhoud streamt. Je krijgt de snelheid van SSG met de flexibiliteit van SSR. Het is het beste van twee werelden, en het is iets dat Gatsby's architectuur nooit kon ondersteunen.

Server Actions zijn aanzienlijk gerijpt. Form handling, mutaties, revalidatie — de patronen zijn goed gevestigd nu en ze hebben veel van de API route boilerplate vervangen die we vroeger moesten schrijven.

// Next.js 15 - Server Action voorbeeld
// app/actions.ts
'use server'

import { revalidatePath } from 'next/cache'

export async function updateProduct(formData: FormData) {
  const id = formData.get('id') as string
  const title = formData.get('title') as string
  
  await db.product.update({
    where: { id },
    data: { title }
  })
  
  revalidatePath(`/products/${id}`)
}

De Turbopack bundler is nu de standaard voor development (en stabiel voor production builds vanaf begin 2026). Koude starttijden voor next dev vielen met 50-70% vergeleken met webpack. Production builds zijn ook sneller, hoewel de verbetering daar bescheidener is — ongeveer 20-30%.

Prestatiebenchmarks: Lighthouse, Bundle Size, Core Web Vitals

Ik draaide benchmarks op equivalente sites — een marketing site met 50 pagina's, blog met 200 posts, afbeeldingszware portfolio sectie. Dezelfde inhoud, dezelfde hosting (Vercel voor Next.js, Netlify voor Gatsby). Hier zijn de resultaten van januari 2026:

Lighthouse-scores (mobiel, mediaan van 5 runs)

Metriek Next.js 15 (App Router) Gatsby 5.13 Next.js 15 (Pages Router)
Performance 96 88 93
Accessibility 98 97 98
Best Practices 100 95 100
SEO 100 100 100
LCP (seconden) 1.1s 1.8s 1.3s
FID/INP (ms) 45ms 120ms 85ms
CLS 0.02 0.08 0.03
TBT (ms) 120ms 380ms 190ms

Bundle Size Vergelijking

Dit is waar het echt interessant wordt. Gatsby verstuurt een client-side runtime die React, de Gatsby runtime en de data laag omvat. Next.js met de App Router en RSC verstuurt aanzienlijk minder JavaScript naar de client omdat Server Components helemaal niet bijdragen aan de client bundle.

Metriek Next.js 15 (App Router) Gatsby 5.13
First Load JS 87 KB (gzipped) 210 KB (gzipped)
Route JS (gem.) 12 KB 45 KB
Total JS (50-page site) 145 KB 380 KB
Image optimization Built-in (on-demand) Build-time (gatsby-plugin-image)
Font optimization Built-in (next/font) Manual of plugin

Het bundle size verschil is grotendeels dankzij RSC. In een typische Gatsby site verstuurt elke component naar de client, zelfs als het alleen statische inhoud rendert. In Next.js met Server Components verstuurt een component die data fetcht en HTML rendert nooit de client bundle. Dat is een massieve winst.

Core Web Vitals in het veld

Lab benchmarks zijn nuttig, maar veldgegevens zijn belangrijker. Op basis van CrUX (Chrome User Experience Report) gegevens van sites waar ik aan heb gewerkt:

  • Next.js sites: 85% slagen in alle drie Core Web Vitals drempels
  • Gatsby sites: 62% slagen in alle drie (vooral falenend op INP en TBT)

De INP (Interaction to Next Paint) metriek is waar Gatsby echt worstelt. De grotere client-side JavaScript bundle betekent meer main thread werk, wat langzamere interacties betekent. Gatsby's hydratiemodel vereist verwerking van de volledige pagina's gegevens op de client, terwijl Next.js met RSC dit volledig vermijdt voor server-gerenderde inhoud.

Next.js vs Gatsby in 2026: The Complete Production Decision Guide - architecture

Architectuurvergelijking: RSC, App Router, SSG, ISR

Renderingstrategieën

Gatsby werd gebouwd rond één renderstrategie: Static Site Generation (SSG). Alles wordt op build-time gebouwd. Gatsby voegde DSG (Deferred Static Generation) toe in v4, wat hun antwoord op Next.js ISR was, maar het vereiste Gatsby Cloud en was nooit zo flexibel.

Next.js geeft je alles:

// Static Generation (equivalent aan Gatsby's standaard)
// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts()
  return posts.map((post) => ({ slug: post.slug }))
}

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const post = await getPost(params.slug)
  return <Article post={post} />
}

// ISR - revalideer elke 60 seconden
export const revalidate = 60

// Of on-demand revalidatie via API route
// app/api/revalidate/route.ts
import { revalidatePath } from 'next/cache'
import { NextRequest } from 'next/server'

export async function POST(request: NextRequest) {
  const { path } = await request.json()
  revalidatePath(path)
  return Response.json({ revalidated: true })
}

Het Data Layer Probleem

Gatsby's GraphQL data laag was innovatief maar werd uiteindelijk een aansprakelijkheidskwestie. Elke gegevensbron had een source plugin nodig. Als de plugin niet bestond of niet werd onderhouden, was je vast code schrijven. De build-time GraphQL schema was krachtig maar voegde aanzienlijke complexiteit en build-tijd toe.

Next.js neemt een ander standpunt in: gewoon gegevens ophalen. Gebruik alles wat je wilt — REST APIs, GraphQL clients, database queries, CMS SDKs. Er is geen framework-opgelegde data laag. Dit is zowel eenvoudiger als flexibeler.

// Next.js - haal data op uit elke bron, op elke manier
async function getProducts() {
  // Direct database query
  const products = await prisma.product.findMany()
  
  // Of REST API
  const res = await fetch('https://api.example.com/products', {
    next: { revalidate: 3600 }
  })
  
  // Of headless CMS SDK
  const entries = await contentful.getEntries({ content_type: 'product' })
  
  return products
}

Voor teams die headless CMS setups gebruiken — Contentful, Sanity, Storyblok, wat dan ook — Next.js is dramatisch eenvoudiger om mee te integreren. Je hebt geen source plugin nodig. Je belt gewoon de API. We dekken dit in detail in ons headless CMS development werk.

Server Components veranderen alles

Ik kom steeds terug op RSC omdat het echt de belangrijkste architecturale verschuiving in React is sinds hooks. Hier is waarom het voor deze vergelijking uitmaakt:

In Gatsby verstuurt je volledige pagina component tree naar de client. Zelfs als een component alleen een lijst met blogtitelpost-titels rendert die uit een CMS zijn opgehaald, worden die componentcode en gegevens geserialiseerd en naar de browser gestuurd voor hydratatie.

In Next.js met RSC draait die component op de server, rendert HTML, en ziet de client nooit de componentcode of de raw gegevens. De browser krijgt HTML. Dat is het.

Dit betekent:

  • Kleinere bundels (zoals hierboven weergegeven)
  • Geen hydratatie mismatch bugs voor server-only components
  • Je kunt server-only code (database queries, file system access) rechtstreeks in components gebruiken
  • Gevoelige gegevens (API keys, business logic) blijft op de server

Ontwikkelaarservaring en ecosysteem

Aspect Next.js 15 Gatsby 5
TypeScript ondersteuning Eersteklas, auto-gegenereerde typen Behoorlijk, maar sommige plugin typen ontbreken
Hot reload snelheid ~200ms (Turbopack) 1-3 seconden (webpack)
Build-tijd (200 pagina's) ~45 seconden ~3-5 minuten
Plugin ecosysteem npm packages (universeel) Gatsby-specifieke plugins (stagnant)
Documentatie Actief onderhouden Grotendeels bevroren sinds 2023
Community (Discord/GitHub) Zeer actief Bijna stil
Jobmarkt vraag Hoog Snel afnemend
Leerresources (2025-2026) Overvloedig Schaars

De kloof in developer experience is dramatisch groter geworden. Next.js met Turbopack geeft je bijna onmiddellijke hot reloads. Gatsby's webpack-gebaseerde dev server voelt naar vergelijking sloomachtig, vooral op grotere sites.

Build-tijden verdienen speciale vermelding. Een 500-page Gatsby site met zware beeldverwerking kon 15-20 minuten duren om te bouwen. De equivalente Next.js site met on-demand beeldoptimalisatie wordt in minder dan 2 minuten gebouwd omdat afbeeldingen op request-time (en vervolgens in cache opgeslagen) worden verwerkt, niet op build-time.

Onze Next.js development team heeft dit zien uitspelen over tientallen projecten. Build-tijden beïnvloeden rechtstreeks de productiviteit van ontwikkelaars en CI/CD-kosten.

Totale eigendomskosten

Laat me over geld praten. Dit is waar de beslissing echt wordt voor zakelijke belanghebbenden.

Hosting-kosten

Scenario Next.js op Vercel Gatsby op Netlify
Kleine site (< 100 pagina's, laag verkeer) $0-20/ma $0-19/ma
Middelgrote site (500 pagina's, 100k bezoeken/ma) $20-150/ma $19-99/ma
Grote site (5000+ pagina's, 1M+ bezoeken/ma) $150-500/ma $99-300/ma*

*Gatsby hosting-kosten zijn lager omdat het zuiver statisch is — geen server compute. Maar je betaalt in build-tijden en build-minuten.

Next.js kan ook worden ingezet op andere platforms: AWS (via SST of Amplify), Cloudflare, zelf-gehost met Node.js. Gatsby's zuiver statische output geeft het meer hosting flexibiliteit in theorie, maar in de praktijk verlies je ISR en alle dynamische features.

Ontwikkelings-kosten

Dit is waar het echte kostenverschil zich bevindt:

  • Gatsby developer tarieven: $120-180/uur (schaars, premium voor legacy kennis)
  • Next.js developer tarieven: $100-200/uur (breder bereik vanwege grotere talentpool)
  • Migratie-kosten (middelgrote Gatsby site → Next.js): $15.000-50.000 afhankelijk van complexiteit
  • Lopend onderhoud (Gatsby): Hoger vanwege dependency management, plugin fixes
  • Lopend onderhoud (Next.js): Lager, meer directe upgrade paden

De verborgen kosten van het blijven op Gatsby zijn technische schuld die dagelijks toeneemt. Elke maand dat je wacht, wordt de migratie iets moeilijker als het Gatsby-ecosysteem verder vervalt.

Voor een gedetailleerde beoordeling van wat een migratie voor je specifieke situatie zou kunnen kosten, bekijk onze pricing pagina of neem contact op.

Migratiepad: Gatsby naar Next.js

Ik heb dit vaak genoeg gedaan om een herhaalbaar proces te hebben. Hier is de high-level aanpak:

Fase 1: Audit (1-2 weken)

  • Maak een inventarisatie van alle Gatsby plugins en hun Next.js equivalenten
  • Wijs de GraphQL data laag toe aan directe API-oproepen of SDK-gebruik
  • Identificeer gatsby-node.js logica (pagina creatie, schema customisatie)
  • Catalogiseer alle dynamische functionaliteit (zoeken, formulieren, auth)

Fase 2: Fundament (1-2 weken)

  • Stel Next.js project in met App Router
  • Configureer TypeScript, ESLint, Tailwind (of je CSS aanpak)
  • Stel de CMS integratie rechtstreeks in (geen source plugins nodig)
  • Implementeer de beeldoptimalisatie strategie met next/image

Fase 3: Pagina migratie (2-6 weken, afhankelijk van grootte)

  • Converteer pagina templates naar Next.js page components
  • Vervang gatsby-image / gatsby-plugin-image met next/image
  • Vervang <Link> van Gatsby met <Link> van Next.js (vergelijkbare API, gelukkig)
  • Migreer gatsby-node.js createPages logica naar generateStaticParams
  • Converteer eventuele gatsby-browser.js / gatsby-ssr.js logica naar layout components

Fase 4: Optimalisatie (1-2 weken)

  • Implementeer ISR waar passend
  • Voeg Server Components toe voor data-zware secties
  • Stel on-demand revalidatie webhooks in van je CMS
  • Prestatietesten en optimalisatie
// Veel voorkomend migratiepatroon: Gatsby page query → Next.js data fetching

// VOOR (Gatsby)
export const query = graphql`
  query BlogPostBySlug($slug: String!) {
    contentfulBlogPost(slug: { eq: $slug }) {
      title
      body { raw }
      publishDate
      heroImage {
        gatsbyImageData(width: 1200)
      }
    }
  }
`

// NA (Next.js App Router)
import { createClient } from 'contentful'

const client = createClient({
  space: process.env.CONTENTFUL_SPACE_ID!,
  accessToken: process.env.CONTENTFUL_ACCESS_TOKEN!
})

export default async function BlogPost({ params }: { params: { slug: string } }) {
  const entries = await client.getEntries({
    content_type: 'blogPost',
    'fields.slug': params.slug,
    limit: 1
  })
  
  const post = entries.items[0].fields
  
  return (
    <article>
      <h1>{post.title}</h1>
      <Image
        src={`https:${post.heroImage.fields.file.url}`}
        width={1200}
        height={630}
        alt={post.title}
      />
      <RichText content={post.body} />
    </article>
  )
}

export const revalidate = 3600 // ISR: revalideer per uur

De grootste gotcha in migratie is de beeldbehandeling. Gatsby's image pipeline was echt uitstekend — de blur-up placeholder, responsive srcsets, lazy loading. Het goede nieuws is dat next/image dit nu allemaal afhandelt, maar de API is anders en je zult elke beeldverwijzing moeten bijwerken.

Wanneer Next.js niet het antwoord is

Ik wil hier eerlijk zijn. Next.js is niet de juiste keuze voor elk project.

Als je absolute eenvoud nodig hebt voor een blog of docs site, overweeg Astro. Astro verstuurt standaard nul JavaScript en heeft uitstekende content collection ondersteuning. Voor puur content-driven sites waar je React's interactiviteit niet nodig hebt, geeft Astro je betere prestaties met minder complexiteit.

Als je een eenvoudige statische site met geen dynamische features bouwt, zelfs 11ty of Hugo zou je beter kunnen dienen. Breng geen framework mee naar een markup gevecht.

Als je vast zit in het Vue- of Svelte-ecosysteem, zijn Nuxt en SvelteKit sterke alternatieven in hun respectievelijke ecosystemen.

Maar als je React nodig hebt, een mix van statische en dynamische inhoud nodig hebt, uitstekende prestaties nodig hebt, en een framework nodig hebt dat jaren voor jaren actief zal worden onderhouden — Next.js is de duidelijke keuze in 2026.

Het verdict

Next.js wint. Het is niet eens dicht, en het is sinds 2022 niet dicht geweest.

Gatsby pionierde belangrijke ideeën in het React-ecosysteem: build-time optimalisatie, image processing pijplijnen, het concept van een uniforme data laag. Deze ideeën leven voort in verschillende vormen in moderne frameworks. Maar als productie framework in 2026 is Gatsby een aansprakelijkheid.

De technische argumenten zijn overweldigend:

  • RSC en de App Router geven Next.js een architecturaal voordeel dat Gatsby niet kan evenaren
  • Bundle sizes zijn 40-60% kleiner
  • Core Web Vitals scores zijn consistent beter
  • ISR en PPR bieden render flexibiliteit die Gatsby nooit behaalde
  • Het ecosysteem bloeit vs. stagnateert

De zakelijke argumenten zijn even duidelijk:

  • Lagere totale eigendomskosten
  • Grotere talentpool
  • Actieve ontwikkeling en ondersteuning van Vercel
  • Duidelijke upgrade paden voor de voorzienbare toekomst

Als je een nieuw project start, gebruik Next.js (of Astro als je React niet nodig hebt). Als je Gatsby in productie draait, begin nu met plannen voor je migratie. Hoe langer je wacht, hoe moeilijker en duurder het wordt.

Heb je hulp nodig bij die migratie? Ons team heeft het vele malen gedaan. Laat het ons weten.

— Aaron Mitchell, Senior Headless Engineer at Social Animal

Veelgestelde vragen

Is Gatsby volledig dood in 2026? Gatsby is niet officieel als end-of-life uitgeroepen door Netlify, maar het is effectief in een onderhouds-only staat. Er is geen significante release geweest sinds v5.13 eind 2023, het kernteam is uiteen gegaan, en het plugin-ecosysteem vervalt. Voor nieuwe projecten is het geen levensvatbare keuze. Voor bestaande projecten moet je een migratie plannen.

Hoe lang duurt het om van Gatsby naar Next.js te migreren? Voor een typische marketing site met 50-200 pagina's, plan op 4-8 weken ontwikkelingstijd. Grotere sites met complexe data relaties, aangepaste plugins, of zwaar GraphQL gebruik kunnen 8-16 weken duren. De grootste variabelen zijn het aantal aangepaste Gatsby plugins die je gebruikt en hoe diep je bent geïntegreerd met Gatsby's GraphQL data laag.

Is Next.js moeilijker te leren dan Gatsby? De App Router en Server Components hebben zeker een leercurve, vooral als je van Gatsby's op pagina's gebaseerde model komt. De mentale model is echter uiteindelijk eenvoudiger — je haalt data rechtstreeks op in plaats van door een GraphQL laag te gaan, en je schrijft components die ofwel op de server ofwel op de client draaien. De meeste ontwikkelaars vinden Next.js meer intuïtief als ze eenmaal voorbij de initiële RSC concepten komen.

Kan ik Next.js zonder Vercel implementeren? Absoluut. Next.js kan worden geïmplementeerd op AWS (met SST, Amplify, of een aangepaste setup), Cloudflare Pages, DigitalOcean, Railway, Fly.io, of zelf-gehost op elke Node.js server. Vercel biedt de meest geoptimaliseerde ervaring, maar je bent niet vastgebonden. Het next start commando draait een standaard Node.js server.

Wat zit met Astro vs Next.js voor statische sites? Voor puur content-driven sites (blogs, documentatie, marketing pagina's met minimale interactiviteit) is Astro vaak een betere keuze. Het verstuurt standaard nul JavaScript en ondersteunt meerdere UI frameworks. Als je React's interactiviteit nodig hebt, dynamische routing, API endpoints, authenticatie, of een mix van statische en dynamische inhoud, is Next.js de betere fit. We werken met beide — bekijk onze Astro development pagina voor meer over wanneer we het aanbevelen.

Hoeveel kost het om van Gatsby naar Next.js te migreren? Ontwikkelings kosten liggen meestal tussen de $15.000 voor een eenvoudige marketing site en $50.000+ voor complexe applicaties met aangepaste data pijplijnen, e-commerce integratie, of internationalisatie. De kosten hangen sterk af van het aantal Gatsby plugins dat moet worden vervangen, de complexiteit van je GraphQL queries, en of je de architectuur wilt moderniseren (ISR, Server Components toevoegen) tijdens de migratie.

Ondersteunt Next.js statische export zoals Gatsby? Ja. next build uitvoeren met output: 'export' in je next.config.js genereert een volledig statische site die overal kan worden gehost — S3, GitHub Pages, elke CDN. Je verliest ISR en server-side features, maar je krijgt hetzelfde implementatiemodel als Gatsby. De meeste teams willen echter geen pure statisch als ze eenmaal de voordelen van ISR en Server Components hebben ervaren.

Wat is er gebeurd met Gatsby Cloud? Gatsby Cloud werd gesloten in Q1 2024, ongeveer een jaar na Netlify's overname. Gebruikers werden gemigreerd naar Netlify's standaard hosting. Dit was een significante klap omdat Gatsby Cloud geoptimaliseerde builds, incrementele builds, en preview functionaliteit bood die nauw verbonden waren met Gatsby's architectuur. Zonder Gatsby Cloud zijn build-tijden op standaard CI/CD platforms aanmerkelijk slechter.