Next.js in mid-2026 is a different framework than the one most engineers learned. The App Router is universal, Turbopack is the default builder, Partial Prerendering is stable, and the caching story finally makes sense without a flowchart. If you froze your knowledge at Next.js 13 or 14, the muscle memory you built is mostly wrong now — but the architectural patterns that replaced it are simpler.

Here is what we are shipping, what we have removed, and what we are watching, based on the projects Techglock has actually deployed in the last six months.

Next.js 15 Is the Floor; Next.js 16 Is Live

Next.js 15 went GA in October 2024. Next.js 16 followed in late 2025. By mid-2026, 15 is the floor for any project we accept maintenance on, and 16 is the default for new builds. The two releases together delivered:

  • React 19 as the supported React version — Actions, useActionState, useOptimistic, and the React Compiler are all wired in by default.
  • Turbopack as the default build engine, replacing Webpack for both dev and build. Cold builds got two to four times faster across our reference projects.
  • Partial Prerendering (PPR) stable — static shells streamed instantly, dynamic content slotted in via Suspense. This is the killer feature most teams haven't fully exploited yet.
  • The new caching defaults — fetch is no longer cached by default, page segments aren't cached by default, and you opt in to caching with "use cache" at the function or page level. This single change ended a year of confusion about "why is my data stale."
  • The after() API — run work after the response has been sent. Logging, analytics, cache invalidations no longer block the user's TTFB.

If your codebase is on Next.js 13 or 14, the migration to 15 is straightforward (create-next-app's codemod handles most of it). The migration from 14 to App Router is the larger lift, and it is overdue.

The App Router Won. Pages Router Is Legacy.

For two years there was a defensible argument for staying on the Pages Router: better library compatibility, simpler mental model, no per-route layout boilerplate. By mid-2026 the ecosystem has fully shifted. Every active library — Auth.js, Drizzle, Prisma, TanStack Query, Hono adapters, every UI kit — defaults to App Router examples. New tutorials skip Pages Router entirely. Even Vercel's own templates are App Router only.

Pages Router still works, and the team has committed to long maintenance. But for any greenfield project, it is the wrong choice in 2026. The mental model — server components by default, client components opted in, file-based routing with co-located data fetching — is materially better for product teams who don't want to think about hydration boundaries.

If you are maintaining a Pages Router app, you do not need to drop everything and migrate. You do need to stop building new pages in it.

Server Actions Are the New API Layer

This is the change that has reshaped the most code we write. Server actions — async functions marked with "use server" — let you call server code directly from a client component without standing up a route handler.

"use server";
import { db } from "@/lib/db";

export async function deletePost(id: string) {
  await db.post.delete({ where: { id } });
  revalidatePath("/posts");
}

That function gets called from a client component as if it were local:

"use client";
import { deletePost } from "./actions";

<button onClick={() => deletePost(post.id)}>Delete</button>

Behind the scenes Next.js handles the RPC, serialisation, revalidation, and progressive enhancement (the action also works without JavaScript when bound to a form). For most internal admin tools and forms, server actions have replaced our entire /api route layer. We still write API routes for genuinely public APIs (webhooks, third-party callbacks, OAuth handlers), but the in-product mutation layer is almost entirely actions now.

Combined with useActionState from React 19, the form-handling code is shorter than anything we wrote in the SPA era.

Partial Prerendering Is the Performance Win Most Teams Are Missing

PPR — Partial Prerendering — lets you serve a static shell instantly while streaming dynamic content into Suspense boundaries. The shell hits TTFB in milliseconds; the dynamic content fills in as it resolves. The user sees something useful immediately, and the dynamic data arrives without a layout shift.

In production it is the difference between a 1.2-second LCP and a 200-millisecond LCP on the same page. We have measured this on every client project where we enabled it. The catch: you have to design pages with PPR in mind — wrapping dynamic sections in <Suspense> with skeleton fallbacks, keeping the static shell genuinely static.

If you have read about PPR and not tried it yet, this is the highest-ROI Next.js feature of 2026. Turn it on for one page, measure the LCP delta, and you will be sold.

Caching Finally Has a Sane Mental Model

Next.js 13 and 14 cached aggressively by default. fetch calls were cached forever unless you passed { cache: "no-store" }. Page segments were cached based on a flowchart that included "the route is dynamic," "a dynamic API was called," "a cookie was read," and several other implicit conditions. Engineers shipped stale data into production and didn't notice until customers complained.

Next.js 15 reversed the defaults. Nothing is cached unless you opt in. The opt-in is "use cache" at the function or component level:

"use cache";
async function getProducts() {
  return db.products.findMany();
}

You can add a cacheTag for invalidation and a cacheLife profile for TTL. The mental model is finally explicit: opt-in, scoped, tagged. We have stopped writing wrapper functions and homemade memoisation for server-side data — "use cache" handles it.

Edge Runtime Is Less Important Than We Thought

In 2023 every Next.js tutorial pushed the Edge Runtime as the future. By mid-2026 the consensus has softened. Edge functions are great for genuinely edge-bound work — geo routing, header rewrites, A/B test assignment, rate limiting. They are worse than Node for almost everything else: cold start jitter, library incompatibilities, observability gaps, and the fact that your database is in one region anyway.

Our default for client work is now: Node runtime for API routes and server components, Edge runtime explicitly chosen for middleware and a small number of latency-sensitive functions. We don't push teams to "go full edge" the way we did two years ago.

The After API and Background Work

The after() API solved a real problem: you want to do some work (log an event, send an email, invalidate a cache) but you don't want it to block the user's response. Before after, you either fired-and-forgot a promise (risky in serverless) or sent the work to a queue.

import { after } from "next/server";

export default async function Page() {
  const data = await getData();
  after(async () => {
    await logAnalyticsEvent({ data });
  });
  return <PageContent data={data} />;
}

The work runs after the response is sent, with the same context as the request. It has replaced about half the cases where we previously used a queue. The other half still need a queue — anything that needs to retry, anything that runs longer than a few seconds, anything cross-tenant — but the simple "log this thing after rendering" case is solved.

The Alternatives Are Real Now

For most product teams, Next.js is still the right default. But by mid-2026 the alternatives are credible enough that "we chose Next because it was the only option" is no longer true:

  • TanStack Start — React Server Components without Vercel-isms. Best alternative for teams that want full type safety and don't need Next.js's deployment story.
  • Astro — best for content-heavy sites where most pages are mostly static. Faster than Next.js on these workloads, simpler mental model.
  • React Router 7 — the framework formerly known as Remix. Strong for traditional web apps, less reliance on React Server Components.
  • SvelteKit — outside the React world, but Svelte 5 with runes plus SvelteKit's deployment story is genuinely competitive for greenfield work.

We have shipped projects on Astro and TanStack Start in the last six months and have not regretted either. Next.js is still our default — particularly for anything with auth, dashboards, or complex mutations — but it is no longer the only credible choice.

The Things You Should Have Already Removed

If you are still doing any of these, modernise:

  • getServerSideProps / getStaticProps in new pages. Use server components.
  • next/image with unoptimized on Vercel. Just let it optimise — it works in 2026.
  • useEffect for data fetching in Server Component pages. Move the fetch to the server.
  • Custom _app.tsx / _document.tsx. The App Router replaces both with app/layout.tsx.
  • Manual revalidation by adding query parameters. Use revalidateTag and cacheTag.
  • Wrapping every fetch with a custom cache layer. "use cache" handles it.

The Migration Path We Recommend

For teams catching up, the rollout order:

  1. Upgrade to Next.js 15 or 16, with React 19. Run the codemod, fix the breaks.
  2. Convert new pages to the App Router while keeping existing Pages Router routes in place. Both can co-exist.
  3. Replace API routes with server actions for any internal mutation. Keep API routes for public APIs and webhooks.
  4. Enable Partial Prerendering on the one or two highest-traffic pages. Measure LCP. Roll out further from there.
  5. Adopt the new caching directives deliberately. Start with the obvious wins (product catalogues, content pages) and grow from there.
  6. Turn on the React Compiler and delete manual memoisation.

The migration is incremental at every step. You do not need a rewrite quarter; you need a sprint to upgrade and a habit of using the new patterns on new code.

What's Coming Next

For the back half of 2026, three things are shaping up:

  • Better dev-loop performance with Turbopack. The current state is already much better than Webpack; the gap is widening every release.
  • Cross-framework Server Functions. Astro, TanStack Start, and React Router 7 are converging on a similar primitive. The pattern will outlast any single framework.
  • Native AI features. Vercel's AI SDK is increasingly part of the Next.js story. Expect deeper streaming + AI primitives in upcoming releases.

If you only do one thing after reading this: turn on Partial Prerendering on your single highest-traffic page, measure the LCP delta, and you will understand the trajectory of Next.js in 2026.