Exploring Whats New and Removed in Next js 16

I recently went through the Next.js 16 beta release, and honestly, it’s a pretty big shift from previous versions. Not just in terms of features, but also in how the framework is evolving. Some things are cleaner now, some old features are gone for good, and a few new tools are still experimental but promising.

If you’re someone like me who builds apps regularly with Next.js, this update is worth paying attention to before you upgrade or start a new project.

Let’s break it down in simple terms — what’s new, what’s changed, and what’s removed.

Turbopack Becomes the Default Bundler

The biggest change in Next.js 16 is that Turbopack is now the default bundler. If you’ve been around since the Webpack days, you know how slow things could get in big projects. Turbopack is built in Rust, and it’s focused on performance.

Builds are now 2–5× faster and hot refresh (or Fast Refresh) can be up to 10× faster. This alone makes development smoother, especially when working with large monorepos or multiple shared components.

You can still switch back to Webpack using:

But ideally, you shouldn’t need to. The caching inside Turbopack is getting better, and it can now reuse cache between restarts, so your dev server boots faster.

Smarter Caching and Revalidation

Caching in Next.js has always been a bit confusing, especially when mixing server actions, dynamic data, and ISR. In version 16, caching APIs are being refined with more clarity.

Key Updates:

1. revalidateTag() now requires a cache life value like "max", "hours", or "seconds".
2. A new method called updateTag() lets you update cache data right after a write action.
3. There’s also refresh(), which refreshes uncached data without resetting the cache.

Here’s an example of how it looks now:

This ensures that the latest data shows up immediately without waiting for the revalidation cycle. If you used revalidateTag in the past, you’ll need to update your code accordingly.

Improved Routing and Navigation

Routing also got smarter in this release. Next.js 16 introduces layout deduplication, which means shared layouts between pages load only once instead of being fetched multiple times.

It also uses incremental prefetching — instead of downloading entire pages ahead of time, Next.js now prefetches only the parts that aren’t already cached. This keeps your app fast and light.

Navigation feels snappier, especially with the combination of Turbopack and smarter cache usage. The best part is, you don’t need to change your existing routing code. The improvements work automatically.

React Compiler Support

Another major step is the built-in support for the React Compiler. It’s not enabled by default yet, but you can try it. The React Compiler automatically optimizes re-renders by analyzing your code.

Think of it as React.memo on steroids — you get fewer unnecessary re-renders without having to wrap every component manually.

It’s still early to rely on it for production, but this direction is great. It moves Next.js toward better performance without putting the burden on developers.

Build Adapters (Alpha)

Next.js 16 introduces a new Build Adapters API. This one is for advanced users or teams deploying to custom environments. With this, you can hook into the build process and tweak the output or integrate custom infrastructure logic.

For example, if you’re deploying to an unusual hosting setup or generating a specific output format, you can use an adapter to control the build output.

It’s still in alpha, but it’s a signal that Next.js is becoming more flexible for enterprise and custom deployment needs.

Updated React and TypeScript Versions

Next 16 uses the latest React 19.2 features, such as:

1. View Transitions for smooth UI transitions
2. useEffectEvent() for cleaner side-effect management
3. Activity API for tracking background operations

Minimum Node.js version is now 20.9+, and TypeScript needs to be 5.1 or above. These updates keep things aligned with modern JavaScript tooling, but they might require updates if your environment is still on older versions.

What’s Removed or Deprecated

Now, the part that usually causes small headaches — what’s removed.

1. AMP is Gone

If you ever used AMP mode in your Next.js apps, it’s time to say goodbye. Support for AMP has been completely removed, along with any config like useAmp or amp: true. Most people stopped using it anyway, so this cleanup makes sense.

2. next lint is Removed

The next lint command is no longer included. You’ll need to run ESLint manually or use Biome. Linting is now decoupled from the Next.js build process.

For example, in your package.json, you can just add:

This gives you more control over linting rules and avoids unwanted overhead during builds.

3. Runtime Config Removed

The old serverRuntimeConfig and publicRuntimeConfig are gone. Next.js now recommends using environment variables via .env files.

So instead of this:

You’d now use:

And access it with:

It’s simpler, more consistent, and works better with serverless deployments.

4. Middleware Renamed to Proxy (Beta Change)

If you’ve used middleware.ts, you might notice it’s being renamed to proxy.ts in the beta version. This reflects its actual role — acting as a proxy between requests, rather than generic middleware.

It’s not a major change, but it will require a file rename and a quick test if you’re using middleware logic for things like authentication or redirects.

5. Synchronous Access Removed

Certain synchronous functions are now asynchronous. You’ll have to await them.

For example:

Becomes:

The same applies to headers() and draftMode() functions. This change helps keep the behavior consistent in server components and actions.

6. Removed Experimental Flags

Some of the old experimental flags have been cleaned up or merged into stable ones:

1. experimental.turbopack → moved to top-level turbopack config
2. experimental.dynamicIO → merged into cacheComponents
3. experimental.ppr (Partial Pre-Rendering) → removed

It’s nice to see these being consolidated. It makes the configuration less messy and easier to understand.

Developer Experience Changes

A few smaller but notable changes:

1. Removed devIndicators like appIsrStatus, buildActivity, and buildActivityPosition.
2. Removed unstable_rootParams(), a new replacement is expected later.
3. Default image quality is now fixed at 75 for <Image> unless you override it.
4. Only modern browsers (Chrome 111+, Edge 111+, Firefox 111+) are officially supported now.

My Thoughts on Upgrading

Next.js 16 feels like a natural evolution — not just a performance upgrade, but a cleanup phase. It removes legacy code paths, simplifies caching, and prepares the framework for the next wave of React improvements.

If you’re maintaining an existing app:

1. Upgrade Node and TypeScript first.
2. Test in a separate branch.
3. Check for removed APIs (especially runtime config and AMP).
4. Update your linting scripts.
5. Test caching and data fetching if you use ISR or server actions.

If you’re starting fresh, it’s a no-brainer to use Next 16. You’ll automatically get Turbopack, React 19 features, and faster feedback loops in development.

Quick Example: Migrating Cache Code

Here’s a simple before-and-after example.

Before (Next 15):

After (Next 16):

This small change ensures your revalidation respects the new caching rules.

Final Thoughts

Next.js 16 is a solid update. It’s not perfect, and some breaking changes might cause short-term pain, but it’s clearly moving in the right direction — more performance, less complexity, and better alignment with React’s future.

For me, the highlights are Turbopack becoming stable, better caching control, and cleaner APIs. The removals might bother you at first, especially if you relied on next lint or runtime configs, but once adjusted, the experience feels smoother overall.

If you plan to upgrade soon, I’d suggest trying it on a side project or staging branch first. Once stable, it’s going to be one of the biggest quality-of-life updates in the Next.js ecosystem in a while.