D
<devtips/>
Guest
What’s in 15.4, what’s landing in 16, and what’s still missing
What 15.4 gave us (and why 16 matters)
Next.js 15.4 landed quietly in July 2025, but it laid serious groundwork: Turbopack was locked in with full test coverage,
cacheComponents entered beta to unify Next's confusing caching behaviors, and new devtools started peeking through. There were also some not-so-quiet hints about what’s being removed: AMP, Node 18, and a few next/image API landmines.All of this tees up Next.js 16, set to drop around October if Vercel follows their usual Ship/Conf release dance. But don’t expect magic. This isn’t a grand LTS moment. It’s more like a stable-ish checkpoint while the team tries to turn beta features into something less experimental.
If you’re a solo founder, indie hacker, or a dev who’s spent too long debugging route behavior you’ll want to know what’s ready to use, what to test first, and what’s still missing.
Turbopack: Fast builds, but dev still hurts
Turbopack is now powering vercel.com, nextjs.org, and a growing number of real-world apps. It’s clearly the future written in Rust, blazing through cold builds, and supposedly replacing Webpack altogether.
In CI? It’s beautiful. In production? Solid.
But in dev?
Even in 15.4, Turbopack struggles in dev mode, especially with:
- Large monorepos
- Custom loaders
- Heavy use of dynamic imports or layouts
Next.js 16 promotes Turbopack to beta, meaning Vercel believes it’s stable enough for real use but developers should still expect hiccups in local dev until future patch releases.
Use it for faster builds and deploys. But test it in dev mode before betting the whole repo on it.
CacheComponents: Finally… maybe?
Next.js devs have been begging for better caching forever. Between
use cache, Partial Prerendering (PPR), and dynamic IO all with slightly different rules—it’s been chaos.Enter
cacheComponents, a new beta flag from 15.4 that combines them all. It promises predictable caching behavior under one umbrella.Sounds great, right?
The potential is real: faster responses, fewer hydration bugs, better edge compatibility. But until cache invalidation becomes easier to understand (and debug), many devs are hesitant.
In 16,
cacheComponents stays in beta, with some improvements:- More consistent revalidation
- Better integration with dynamic routes
- Slightly improved logging (if you squint)
Try it on read-heavy pages (blogs, docs, pricing), but hold off for real-time or user-specific content.
App Router & DX upgrades
App Router has matured since its awkward 13.x debut. 15.4 added smarter prefetching and minor routing tweaks, but 16 finally brings real tooling to the table:
Route-inspector
Visualize your entire route tree, see which components are loading or cached, and catch route mismatches faster. No more guessing what’s rendering where.
Log forwarding
Browser logs are forwarded directly to your terminal, including hydration warnings and route-level errors. It’s not polished yet, but it’s a huge step forward in debugging UX.
These tools are preview quality, but useful. Expect more polish in 16.1+.
Press enter or click to view image in full size
Middleware is stable, deployment adapters aren’t
Node.js middleware: ready to roll
First introduced in 15.2, Node-based middleware is finally being marked stable in 16. It’s great for:
- Auth
- Request logging
- Localization and rewrites
It runs with full Node API support no edge runtime quirks and behaves predictably in production. That’s a win.
Deployment adapters: still alpha
Next.js 16 adds experimental support for custom deployment targets (e.g. Docker, self-hosted, edge). In theory, this unlocks real portability beyond Vercel.
But in practice?
- Ecosystem support is limited
- Docs are light
- Self-hosting remains complex
Middleware:
Deployment adapters: (use with caution)
Breaking changes and missing pieces
Like every big Next.js release, 16 comes with migration friction.
What’s breaking:
- Node 18 support dropped → Upgrade to Node 20+
- AMP removed → You’re welcome
- next/image API updated → Codemods provided, but test everything image-heavy
Still missing:
- A lightweight mode for small apps
- Simpler routing without
layout.jsmental gymnastics - Reliable cache invalidation tools
- Up-to-date, centralized documentation
Despite solid updates, many devs feel like they’re beta testing a production tool. And yeah, it kinda feels like that sometimes.
Before we dive into whether you should upgrade, here’s a quick feature status breakdown:
Feature status at a glance:
Press enter or click to view image in full size
Should you upgrade?
Here’s the quick TL;DR:
You should upgrade if:
- You want faster build times (Turbopack)
- You use App Router and want better debugging
- You need stable middleware for auth or rewrites
- You’re experimenting on a new app and like shiny things
Maybe wait if:
- You rely on third-party packages still catching up
- You self-host and don’t want to debug deployment adapters
- You want rock-solid caching and a stable upgrade path
Try it in a branch, run through your core flows, and benchmark builds before going all in.
Final thoughts
Next.js 16 isn’t some revolutionary drop it’s the mid-season patch where things start working better, but not without pain.
- Devtools are finally helpful
- Turbopack is close to real stability
- Middleware is usable in production
But…
- Caching is still murky
- Dev-mode speed isn’t there yet
- Docs and DX need serious cleanup
So yeah it’s progress. But it’s not peace.
If you’re the type to embrace early features and don’t mind a few rough edges, 16 is worth your time.
If you’re shipping to prod on Fridays? Maybe stay on 15.4 and let the brave ones test the waters.
Useful links
- Next.js 15.4 release blog
- Turbopack overview
- Route-inspector preview
- Reddit: r/nextjs
- Next.js GitHub issues
Continue reading...
