Waarom Next.js mijn default stack is in 2026

Elk jaar krijg ik dezelfde vraag: "waarom eigenlijk Next.js?" De eerlijke versie: omdat het in productie werkt, het ecosysteem volwassen is, en het de kosten per feature laag houdt. Onder dezelfde motorkap zit namelijk een React frontend, een Node.js backend en een CDN-vriendelijke output - die combinatie levert simpelweg de hoogste waarde per development uur op.

Wat Next.js goed doet

Server Components schrappen halve netwerk round-trips. In Pages Router-tijden begon elke pagina met een lege shell die daarna client-side data fetcht. Nu render ik vanaf Next.js 14 de initiele HTML server-side, inclusief data, en valt de eerste paint binnen de LCP-budget zonder extra optimalisatie. Google ziet exact dezelfde content als de gebruiker.

Metadata API is een zegen voor SEO. generateMetadata() per route geeft je per-page titles, descriptions, canonicals en Open Graph graphics zonder een extra library. Gecombineerd met sitemap.ts en robots.ts in de App Router heb je de hele SEO-fundering in drie bestanden.

Image en Font optimalisatie is ingebouwd. next/image doet automatisch responsive sizing, AVIF/WebP conversie en lazy loading. next/font laadt Google Fonts zonder CLS. Twee van de grootste performance killers zijn opgelost voordat ik iets configureer.

Edge runtime wanneer het hoort. Lichte routes zoals contactformulieren of webhooks draaien op de Cloudflare edge, zwaardere routes op Node.js. Dezelfde codebase, verschillende runtimes per handler.

Waar de pijn zit

Next.js is niet gratis. Een paar scherpe randen die ik vaak zie:

1. Hydration mismatch errors bij new Date() of Math.random() in Server Components. Zodra je lokale tijd rendert, zet het in een Client Component of serialiseer expliciet.
2. "use client" besmet omhoog. Importeer je in een Server Component een Client Component, prima. Andersom wordt het hele importpad client-side. Een verdwaalde framer-motion in je layout en je hebt ineens een 300 KB client bundle.
3. Caching is krachtig maar onzichtbaar. fetch() in App Router cachet standaard. Als je prijs-data ververst moet worden, moet je expliciet revalidate zetten of no-store. Veel bugs ontstaan hier.
4. Minor versies breken soms. Tussen 14 en 15 veranderde de handling van params en searchParams naar Promises. Niet catastrofaal, wel een middagje werk op een grote codebase.

Wanneer ik géén Next.js kies

Statische brochure site zonder dynamiek → Astro is lichter en sneller te builden. Next.js is overkill als er geen server-side renders of user state zijn.

Real-time collaborative app (Figma-style) → Die hoort op een dedicated Node.js + WebSocket stack of zelfs op Cloudflare Durable Objects te draaien, niet als Next.js route.

Desktop-first Electron app → Next.js kan wel, maar dan draag je onnodig framework gewicht mee. Een pure Vite + React setup is lichter.

De rest van de stack

Naast Next.js zitten deze vrijwel altijd in elk project:

• TypeScript - niet onderhandelbaar. Kost extra setup op dag 1, bespaart vier weken bugs op dag 90.
• Tailwind CSS v4 - utility-first styling met @theme config. Geen CSS-in-JS runtime cost, geen Specificity oorlog.
• Drizzle ORM - TypeScript-native, geen decorator magie, SQL blijft zichtbaar. Migraties zijn gewoon SQL bestanden.
• Docker + Docker Compose - zelfde stack lokaal, staging en productie. Geen "it works on my machine".
• Cloudflare - CDN, DDoS bescherming, edge workers en DNS in één. Goedkoper dan een vergelijkbare stack bij AWS.

Conclusie

Next.js is geen hype-keuze meer, het is infrastructure. Het wint niet elke benchmark, maar het verliest ook bijna nooit een delivery. Voor 80% van de web- en SaaS projecten die bij me langskomen - van een landing page tot Salonnare - is het de snelste weg van idee naar productie.

De overige 20% is waar je echte engineering judgment nodig hebt. Daar ben ik consultant, niet fan.