If you've been around React for a while, you remember Pages Router. It worked, but dragged a lot of
baggage: `getServerSideProps`, `_app.tsx`, mixed runtimes. With App Router (stable since Next.js 13,
mature in Next.js 16), Vercel reshuffled the deck: server-first, nested layouts, native streaming.
This guide explains why App Router is the 2026 default and what Next.js 16 brings over previous
versions.
## Server-first by default
In App Router, every component is a **Server Component** unless you mark it `'use client'`. That
changes how you think:
- DB calls go straight into the component, no `getServerSideProps`.
- The client JS bundle drops sharply (server-only code stays on the server).
- Server-side deps (Prisma, heavy SDKs) don't pollute the client.
```tsx
// Server Component - default
import { db } from '@/lib/db/client';
export default async function PostsPage() {
const posts = await db.post.findMany();
return (
{posts.map((p) => (
- {p.title}
))}
);
}
```
No `getServerSideProps`. No prop drilling. No SWR for data only the server reads.
## Nested layouts
Each folder can have its own `layout.tsx`. Layouts persist across navigations (don't re-mount),
which improves UX and saves work:
```
app/
layout.tsx ← root layout (HTML, fonts)
dashboard/
layout.tsx ← persistent sidebar
page.tsx ← dashboard home
settings/
page.tsx ← content changes, sidebar stays
```
In Pages Router you simulated this with `_app.tsx` and tricks. In App Router it's native.
## Streaming and Suspense
You can render partially: show the layout fast and fill heavy parts as they arrive. `
`
with a per-folder `loading.tsx` gives progressive spinners without you writing state.
```tsx
}>
```
The user sees UI before the whole page is ready.
## Server Actions
Server Actions are server-side functions invoked from the client with no explicit endpoint. For
forms and mutations it's the most comfortable thing React has ever had.
```tsx
'use server';
export async function createPost(formData: FormData) {
await db.post.create({ data: { title: formData.get('title') as string } });
}
```
No `/api/posts/create`, no fetch, no duplicated types. Modern boilerplates wrap them in helpers like
`createAuthenticatedAction` for validation + auth.
## What Next.js 16 brings
Next.js 16 consolidates the trajectory:
- **Stable `cacheComponents`**: granular opt-in caching per component. Fine control over what caches
and what revalidates.
- **Stable Turbopack** for production. Builds and dev far faster than webpack.
- **React 19 compatibility**: improved Server Actions, `use()` for promises, better transitions.
- **Polished DX**: clearer errors, more readable console output, stack traces that point to the
right place.
## Common pitfalls when migrating
**1. Defaulting to `'use client'`**: turn it on and you lose server-first. Only use it when needed
(hooks, events, browser APIs).
**2. Calling hooks in Server Components**: not possible. If you need state, that part is client.
**3. Importing heavy SDKs in the client**: Prisma, AWS SDK, etc., are server-only. Import them in
client components and the bundle blows up.
**4. Not using nested layouts**: if everything hangs off the root layout, you lose persistence
across navigations. Use the hierarchy.
## When NOT to use App Router yet
Almost never. In 2026 App Router is mature. The only real case is a legacy project deep in Pages
Router with no migration budget. New project: App Router every time.
## Bottom line
Next.js 16 + App Router is the reasonable default for SaaS in 2026. Server-first, nested layouts,
streaming, Server Actions, and `cacheComponents` cover 95% of needs without extra libraries.
If your boilerplate still ships Pages Router in 2026, technical debt will catch up with you. And if
you're starting something new, the decision is already made before day 1.
Enjoyed this article?
Subscribe for more tutorials and tips on building products with AI
CREA.MBA