Why Next.js is my default stack in 2026

Every year I get the same question: "why Next.js, actually?" The honest version: because it works in production, the ecosystem is mature, and it keeps cost-per-feature low. Under the same hood you get a React frontend, a Node.js backend and a CDN-friendly output - that combination simply delivers the highest value per development hour.

What Next.js does well

Server Components cut out half the network round-trips. In the Pages Router days every page started with an empty shell that then fetched data client-side. Since Next.js 14 I render the initial HTML server-side, data included, and the first paint lands inside the LCP budget without extra optimisation. Google sees exactly the same content as the user.

The Metadata API is a gift to SEO. generateMetadata() per route gives you per-page titles, descriptions, canonicals and Open Graph images without an extra library. Combined with sitemap.ts and robots.ts in App Router you have the entire SEO foundation in three files.

Image and font optimisation is built in. next/image does automatic responsive sizing, AVIF/WebP conversion and lazy loading. next/font loads Google Fonts without CLS. Two of the biggest performance killers are solved before I configure anything.

Edge runtime when it fits. Light routes like contact forms or webhooks run on the Cloudflare edge, heavier routes on Node.js. Same codebase, different runtime per handler.

Where the pain lives

Next.js isn't free. A few sharp edges I see often:

1. Hydration mismatch errors with new Date() or Math.random() in Server Components. As soon as you render local time, put it in a Client Component or serialise explicitly.
2. "use client" propagates upward. Importing a Client Component in a Server Component is fine. The other way makes the full import path client-side. A stray framer-motion in your layout gives you a 300 KB client bundle.
3. Caching is powerful but invisible. fetch() in App Router caches by default. If pricing data needs to refresh, you must explicitly set revalidate or no-store. Many bugs are born here.
4. Minor versions occasionally break. Between 14 and 15 the handling of params and searchParams changed to Promises. Not catastrophic, but half a day of work on a large codebase.

When I pick something else

Static brochure site with no dynamics → Astro is lighter and faster to build. Next.js is overkill without server-side renders or user state.

Real-time collaborative app (Figma-style) → Belongs on a dedicated Node.js + WebSocket stack or Cloudflare Durable Objects, not a Next.js route.

Desktop-first Electron app → Next.js works, but you drag along unnecessary framework weight. A pure Vite + React setup is lighter.

The rest of the stack

Beyond Next.js, these are almost always in every project:

• TypeScript - non-negotiable. Costs extra setup on day 1, saves four weeks of bugs on day 90.
• Tailwind CSS v4 - utility-first styling with @theme config. No CSS-in-JS runtime cost, no specificity war.
• Drizzle ORM - TypeScript-native, no decorator magic, SQL stays visible. Migrations are plain SQL files.
• Docker + Docker Compose - same stack locally, staging and production. No "works on my machine".
• Cloudflare - CDN, DDoS protection, edge workers and DNS in one. Cheaper than a comparable AWS stack.

Conclusion

Next.js is no longer a hype choice, it's infrastructure. It doesn't win every benchmark, but it almost never loses a delivery. For 80% of the web and SaaS projects that come my way - from a landing page to Salonnare - it's the fastest path from idea to production.

The remaining 20% is where you need real engineering judgement. There I'm a consultant, not a fan.