What we ship when we ship Next.js 15
App Router, RSC, Turbopack. Where the gains land, where the gotchas hide, and what we'd still pick today.
Next.js 15 isn't a marketing version bump. The combination of stable App Router, mature React Server Components, and Turbopack-by-default in dev is the first time we've reached for the framework without hesitating about the trade-offs.
Where it earns its keep
Server Components flip the cost model. The default is server-rendered, server-fetched, zero-JS — and you opt in to interactivity, not out of it. For a marketing site like this one, that's the right shape: most pages stay under 110 KB of JavaScript despite using a modern animation library, a CMS, and procedural SVG.
Turbopack in dev is finally faster than Webpack, which sounds boring but used to be a flat lie. Our /studio route (Sanity Studio, 1.5 MB) compiles in under a second cold; the public routes hot-reload in under 250 ms.
Where it bites
The pathnames story for next-intl is more rigid than you'd like. Per-locale dynamic slug routes need either object-form Links or a typed escape hatch. We picked the latter once at the Link primitive level and didn't pay the cost again.
View Transitions API is still patchy: Safari has shipped only enough of it to be teased by the dev tools. We use it for hard navigation and a Motion-based crossfade for client navigation. It's two implementations for one feature, but the failure modes are well-understood.
We don't take new tech because it's new. We take it when the failure modes are smaller than what we already ship.
What we'd skip
Parallel routes for our scale. The mental model is right, the tooling is fragile, and the use cases we hit are better solved with composition. Maybe in a year.
Citations
Cite this article
Copy the citation block — formatted the way our LLM-friendly markup expects it (BRIEF §10.3 #4).
Andrea Ventura (). “What we ship when we ship Next.js 15.” NEXUS Journal. http://localhost:3000/en/journal/shipping-nextjs-15