Tu "Hola Mundo" en App Router ya Sirve ~80kB de JavaScript y No Puedes Leer un POST Body en Middleware
Si empezaste un proyecto con Next.js App Router en 2024, esto es lo que tienes:
Una página que podría ser HTML estático sirviendo decenas de kilobytes de JavaScript. Un middleware que no puede leer el cuerpo de una petición POST. Y una dependencia tácita de Vercel para que funciones como ISR funcionen sin montarte una infraestructura paralela.
*El problema no es que Next.js sea malo. Es que el "solo usa Next.js" se ha convertido en un reflejo que la mayoría no cuestiona. *
Y cuando lo cuestionan, ya es tarde.
---
El App Router No Resuelve Tu Problema. Crea Otros Nuevos
La Promesa vs. La Realidad
La narrativa dominante dice: el App Router es el futuro. Server Components reducen el bundle. Las nested layouts son más potentes. El streaming SSR mejora el rendimiento percibido.
La realidad para el 80% de los proyectos:
❌ Tienes una web corporativa, un blog, o un e-commerce simple. No necesitas layouts anidados de 5 niveles con parallel routes. Necesitas un header, un footer, y contenido.
❌ Tu equipo pierde horas con errores de "use client". El error "You're importing a component that needs useState but it's a Server Component" es una clase de bug que simplemente no existía con Pages Router.
❌ El rendimiento prometido no llega. Un "hello world" en App Router genera ~70-90kB de JavaScript gzippped antes de escribir una línea de tu código. El equivalente en Pages Router: ~35-45kB.
✅ Pages Router sigue funcionando, sigue soportado, y para la mayoría de los proyectos es la opción técnicamente superior.
La Complejidad se Ha Triplicado
Pages Router requería entender 2 convenciones de ficheros especiales: pages/_app y pages/_document.
App Router requiere entender 7+: layout, page, loading, error, not-found, route, template.
Cada uno con su propio comportamiento, orden de anidamiento, y reglas de herencia. Y eso antes de tocar generateStaticParams, generateMetadata, o las Server Actions.
*No es que el App Router sea complejo porque resuelve problemas complejos. Es complejo porque su modelo mental es inherentemente más difícil de razonar. *
---
El Impuesto del 'use client' que Nadie Cuantifica
El Cambio Silencioso de Modelo Mental
En Pages Router, cada componente era cliente por defecto. Simple. Predecible. Depurable.
El App Router invierte esto: los Server Components son el default. Esto reduce el bundle en teoría. En la práctica:
Una encuesta de la comunidad React en 2023 mostró que ~40% de los desarrolladores reportaron confusión sobre el límite entre server y client components.
Cada botón. Cada formulario. Cada date picker. Cada dropdown. Necesita 'use client'.
*El ahorro teórico de bundle de los Server Components se diluye cuando el 60% de tus componentes acaban siendo clientes de todas formas. *
El Debugging Fantasma
Lo peor no es poner 'use client'. Es cuando olvidas ponerlo y el componente funciona en desarrollo pero se rompe en producción porque una biblioteca de terceros intenta acceder al DOM en el servidor.
Horas de debugging para un error que, en Pages Router, directamente no existía.
---
El Middleware Tiene Limitaciones que Descubres en Staging
El Problema del POST Body
El middleware de Next.js corre en Edge Runtime. Edge Runtime soporta solo ~40% de las APIs de Node.js.
El caso concreto: necesitas leer el body de una petición POST en el middleware para decidir si redirigir o no.
*El middleware de Next.js es elegante en el slide de una keynote. En producción, sus limitaciones crean bugs invisibles que descubres cuando tu autenticación falla silenciosamente. *
---
El Lock-In de Vercel es Gradual, No Abrupto
Cada Feature te Aleja un Paso de la Salida
Vercel no te ata con un contrato. Te ata con conveniencia.
Entre 2023 y 2024, Vercel introdujo:
- Vercel KV para persistencia de ISR
- Vercel Postgres para Server Actions
- Vercel Blob para subida de ficheros
- Vercel Toolbar para edición visual
Cada feature individual es útil. Acumulados, crean una barrera de migración.
Si mañana quieres migrar a AWS, Cloudflare, o self-hosted:
- ISR necesita una base de datos compartida (Redis / Vercel KV) para persistir caché entre nodos
- Image Optimization necesita configuración extra
- Middleware Edge Functions no se traducen directamente
*No es que no puedas hostear Next.js fuera de Vercel. Es que cada feature que uses de su ecosistema te exige una reescritura parcial si decides irte. *
El Ejemplo Concreto: ISR Self-Hosted
En Vercel, ISR funciona con un clic. Literalmente.
Fuera de Vercel:
*El 90% de los tutoriales te muestran el caso "en Vercel". Nadie te enseña el coste real de salir. *
---
El Marco de 4 Pasos para Decidir si el App Router te Conviene
Paso 1: Audita tus Necesidades Reales
Pregúntate:
- ¿Tienes layouts anidados de 3+ niveles con datos compartidos? (Dashboards, portales multi-tenant) → App Router puede valer la pena.
- ¿Tienes un header + footer y páginas planas? → Pages Router o Astro son mejores.
*La mayoría de los proyectos caen en el segundo grupo y están pagando la complejidad del primero. *
Paso 2: Define tu Presupuesto de Lock-In
Antes de adoptar cualquier feature de Next.js 14+ (ISR, Middleware, Image Optimization, Vercel KV, Vercel Postgres):
- Busca si funciona en tu plataforma de deploy objetivo
- Si solo funciona sin fricción en Vercel, pregúntate si el feature vale la dependencia
- Documenta esa decisión para que el equipo sepa a qué se ata
Paso 3: Higiene Estricta del 'use client'
Adopta estas reglas desde el día 1:
- Los Server Components son el default
- Pon
'use client'solo en componentes hoja (leaf components) - Añade reglas de lint en CI que detecten creep accidental de client components
- Mide mensualmente tu ratio server/client components
Paso 4: Mide el Bundle Real
Usa next-bundle-analyzer y mide tu baseline:
Si tu baseline supera los 100kB gzippped para una página simple, pregúntate:
- ¿Pages Router reduciría esto a la mitad?
- ¿Podrías migrar a Astro o Vite + React Router?
---
La Verdad Incómoda
Next.js no es mal software. Es software que ha crecido en complejidad para resolver problemas que la mayoría de los equipos no tiene.
El App Router tiene caso de uso legítimo: dashboards complejos, portales con layouts profundos, aplicaciones que necesitan streaming SSR real.
Pero si estás construyendo una web corporativa, un blog, o un SaaS con páginas mayormente estáticas y algo de interactividad — estás pagando un impuesto de complejidad que no deberías pagar.
El Pages Router no está deprecado. Sigue recibiendo soporte. La presión social para migrar al App Router viene de tutoriales y conferencias, no de necesidades técnicas reales.
*Elige la herramienta que resuelve tu problema de hoy. No la que promete resolver el problema que tendrás dentro de dos años. *
A veces, la decisión más valiente no es adoptar lo nuevo. Es reconocer que lo que ya funciona sigue siendo la mejor opción.
Artículos relacionados
- Next.js 16 New Features: Las 3 que Ponen Tu Proyecto en Riesgo (y Cómo Sortearlas)
- Next.js 16 New Features: Las 3 que Multiplican Tu Velocidad (y las Otras Que Son Humo)
- Server Components: El Error de Arquitectura que Anula el Rendimiento en Next.js 16
- Next.js 16 New Features: Las 5 Que Multiplican tu Velocidad de Deploy (y las 3 Trampas que Nadie Cuenta)
- Next.js 16: Las Features que el 90% de Developers Todavía No Entienden
---
¿Quieres recibir contenido como este cada semana? Suscríbete a mi newsletter
