Por qué Next.js 16 con App Router es el default en 2026

Si llevas tiempo en React, recordarás Pages Router. Funcionaba, pero arrastraba mucho lastre: `getServerSideProps`, `_app.tsx`, runtime mezclado. Con App Router (estable desde Next.js 13 y maduro en Next.js 16), Vercel cambió la baraja: server-first, layouts anidados y streaming nativo. Esta guía explica por qué en 2026 App Router es el default y qué te llevas en Next.js 16 respecto a versiones anteriores. ## Server-first por defecto En App Router, todos los componentes son **Server Components** salvo que pongas `'use client'`. Eso cambia cómo piensas: - Las llamadas a base de datos van directas en el componente, sin `getServerSideProps`. - El bundle de JS al cliente baja drásticamente (no se envía código que solo corre en server). - Las dependencias de servidor (Prisma, SDKs pesados) no contaminan el cliente. ```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}
))}

); } ``` Sin `getServerSideProps`. Sin props drilling. Sin SWR para datos que solo lee server. ## Layouts anidados Cada carpeta puede tener su `layout.tsx`. Los layouts persisten entre navegaciones (no se re-montan), lo cual mejora UX y reduce trabajo: ``` app/ layout.tsx ← root layout (HTML, fonts) dashboard/ layout.tsx ← sidebar persistente page.tsx ← home del dashboard settings/ page.tsx ← cambia el contenido, sidebar sigue ``` En Pages Router esto se simulaba con `_app.tsx` y trucos. En App Router es nativo. ## Streaming y Suspense Puedes hacer "render parcial": muestras el layout rápido y rellenas las partes pesadas conforme llegan. `` con un `loading.tsx` por carpeta da spinners progresivos sin que escribas estado. ```tsx }> ``` El usuario ve UI antes de que toda la página esté lista. ## Server Actions Server Actions son funciones que corren en server y se invocan desde el cliente sin endpoint explícito. Para formularios y mutaciones es lo más cómodo que ha tenido React. ```tsx 'use server'; export async function createPost(formData: FormData) { await db.post.create({ data: { title: formData.get('title') as string } }); } ``` Sin `/api/posts/create`, sin fetch, sin types duplicados. El boilerplate moderno los envuelve en helpers tipo `createAuthenticatedAction` para validación + auth. ## Qué trae Next.js 16 Next.js 16 consolida lo que veníamos viendo: - **`cacheComponents`** estable: opt-in granular al cacheo del componente. Te quedas con control fino sobre qué se cachea y qué se revalida. - **Turbopack** estable también para producción. Builds y dev mucho más rápidos que con webpack. - **Compatibilidad con React 19**: Server Actions mejoradas, `use()` para promises, mejor manejo de transiciones. - **DX más cuidada**: errores más claros, mensajes en consola más legibles, stack traces que apuntan al sitio correcto. ## Errores comunes al migrar **1. Usar `'use client'` por defecto**: lo activas y pierdes el server-first. Ponlo solo cuando hace falta (hooks, eventos, browser APIs). **2. Llamar a hooks en Server Components**: imposible. Si necesitas estado, esa parte es client. **3. Importar SDKs pesados en client**: Prisma, AWS SDK, etc., son server-only. Si los importas en componente cliente, peta el bundle. **4. No usar layouts anidados**: si todo cuelga del layout raíz, pierdes la persistencia entre navegaciones. Aprovecha la jerarquía. ## Cuándo NO usar App Router todavía Casi nunca. En 2026 App Router es maduro. El único caso real es un proyecto legacy con Pages Router profundo que no tienes presupuesto para migrar. Pero un proyecto nuevo: App Router siempre. ## Conclusión Next.js 16 + App Router es el default razonable para SaaS en 2026. Server-first, layouts anidados, streaming, Server Actions y `cacheComponents` cubren el 95% de necesidades sin recurrir a librerías extras. Si tu boilerplate sigue en Pages Router en 2026, la deuda técnica te va a pesar. Y si arrancas algo nuevo, la decisión está tomada antes de empezar.