¿El principio del fin para Next.js? Entre la complejidad y el “Vercel-centrismo”
Tabla de Contenidos
Abrir tabla de contenidos
La “App Router-ización” del caos
El mayor punto de quiebre fue la transición al App Router. Lo que se vendió como el futuro con React Server Components (RSC), se sintió para muchos como un cambio de reglas a mitad del partido.
- Curva de aprendizaje: Pasamos de un sistema de archivos intuitivo a una estructura plagada de archivos especiales (
layout.js,template.js,error.js). - Abstracción excesiva: El manejo de caché por defecto se volvió tan agresivo y complejo que diagnosticar por qué un dato no se actualiza en producción se ha convertido en una tarea de “magia negra” para muchos ingenieros.
El impacto técnico: Rendimiento y DX
No todo es “chisme” de Twitter; hay implicaciones técnicas reales, especialmente cuando hablamos de Web Vitals y escalabilidad:
1. El mito de la velocidad con RSC
Aunque los Server Components prometen reducir el bundle de JavaScript en el cliente, la realidad es que la latencia del servidor se ha vuelto el nuevo cuello de botella. Si tu arquitectura de datos no es perfecta, el tiempo de respuesta (TTFB) se dispara mientras el servidor intenta resolver árboles de componentes complejos antes de enviar el primer byte.
2. El laberinto del Hydration
La hidratación en Next.js sigue siendo un reto. Al intentar mezclar componentes de servidor y de cliente, es común caer en errores de mismatch que no solo rompen la experiencia de desarrollo (DX), sino que penalizan el Total Blocking Time (TBT), afectando directamente el SEO y la retención de usuarios en sitios de alto tráfico.
3. Client-side vs Server-side: La pelea por los recursos
En proyectos de e-commerce, donde cada milisegundo cuenta, la sobrecarga de manejar estados globales complejos sobre una estructura de Server Components puede resultar contraproducente. La penalización en el rendimiento al intentar “re-hidratar” islas de interactividad puede anular las ventajas de tener un HTML inicial rápido.
¿Framework abierto o producto de Vercel?
Existe una queja persistente: Next.js se está optimizando para jalar chido exclusivamente en Vercel. Intentar desplegar una aplicación moderna de Next.js en un servidor independiente (un VPS con Docker o S3) se ha vuelto una misión de “picar piedra”. Si no estás en su infraestructura, la configuración de las cabeceras de caché y las funciones edge se vuelve un dolor de cabeza innecesario.
El ascenso de la competencia
Mientras Next.js se vuelve más robusto pero pesado, otros jugadores están aprovechando el descuido:
- Remix: Con un enfoque más apegado a los estándares web y una gestión de datos más predecible.
- Astro: El favorito para quienes buscan velocidad pura eliminando el JavaScript innecesario.
Conclusión: ¿Vale la pena saltar del barco?
No nos hagamos bolas: Next.js no va a morir mañana. Sigue siendo la herramienta más potente para proyectos empresariales por su enorme ecosistema. Pero la “época dorada” de la confianza ciega se terminó.
Hoy, ser un buen ingeniero significa cuestionar si realmente necesitas toda la complejidad que Next.js impone o si una herramienta más ligera te daría mejores resultados sin tantas canas verdes.