Next.js, desarrollado por Vercel, es un framework de React que ha revolucionado la manera en la que se construyen aplicaciones web, ofreciendo una integración optimizada del renderizado del lado del servidor (SSR) y generación de sitios estáticos (SSG), entre otras características. Esta herramienta ha sido un punto de inflexión para desarrolladores que buscan simplicidad, velocidad y un buen rendimiento sin dejar de lado la flexibilidad. Sin embargo, a pesar de su popularidad creciente, en los últimos tiempos se ha observado una oleada de críticas y cuestionamientos en torno a su funcionalidad y estabilidad, especialmente provenientes de desarrolladores con experiencia y aquellos involucrados en proyectos de mayor envergadura y duración. El surgimiento de esta ola crítica podría atribuirse a varias causas interrelacionadas que comenzaron a manifestarse a medida que el uso de Next.
js se fue ampliando y diversificando más allá de proyectos iniciales o pruebas de concepto. Los primeros usuarios y defensores del framework lo adoptaron motivados por el impulso a la productividad y la facilidad para crear aplicaciones visibles y funcionales en poco tiempo. Sin embargo, conforme el ecosistema se hizo más sofisticado y las expectativas crecieron, las limitaciones y problemas subyacentes comenzaron a aparecer con mayor nitidez. Uno de los puntos que más ha generado frustración tiene que ver con las llamadas Server Actions que Next.js implementa.
Estas acciones, que en teoría deberían mejorar la integración y el manejo del procesamiento del lado servidor, funcionan de manera secuencial, lo que provoca cuellos de botella y ralentizaciones en operaciones que, en otros entornos, podrían ejecutarse de forma paralela y mucho más eficiente. Esta característica ha llevado a que algunos desarrolladores prefieran descartar su uso, incluso cuando la documentación oficial promociona su utilidad. En paralelo, el llamado App Router, que se encarga de gestionar la navegación y el enrutamiento interno de las páginas, presenta también limitaciones evidentes. Cada cambio de ruta provoca solicitudes al backend, y aunque existen mecanismos de prefetch para adelantar la carga de recursos, estos no cubren todos los escenarios, especialmente en aplicaciones con estructuras de rutas complejas. Esto deriva en un proceso de prueba y error que entorpece la experiencia del desarrollador y, en algunos casos, obliga a implementar soluciones personalizadas para suplir estas carencias de Next.
js. Las actualizaciones de versiones mayores tampoco han sido una experiencia fluida para todos. La transición de Next.js 14 a 15, pese a estar acompañada de codemods e instrucciones para facilitar la migración, ha causado problemas inesperados, como el incremento en el tamaño de las cabeceras HTTP que genera conflictos con proxies reversos. Específicamente, la introducción de reactMaxHeadersLength ha supuesto un inconveniente omitido en las notas oficiales, lo que evidencia una falta de comunicación clara y anticipación por parte del equipo de desarrollo del framework.
Un aspecto clave que también ha sido objeto de críticas es la gestión de dependencias internas. Next.js incluye sus propias versiones de ciertas librerías, lo que puede generar comportamientos contraintuitivos o incompatibilidades difíciles de identificar, afectando el desarrollo cotidiano y la depuración de errores. Esta sobrecarga oculta dentro del framework aumenta la complejidad y va en contra de la filosofía de transparencia y control que esperan muchos desarrolladores profesionales. El desglose entre componentes que deben marcarse con "use client" o "use server" ha generado confusión adicional.
Mientras que algunos componentes asincrónicos son compatibles en el lado servidor, otros no lo son en el cliente, lo que ha llevado a que numerosos desarrolladores opten por aplicar indiscriminadamente "use client" para evitar sorpresas, elevando la carga de mantenimiento y afectando la claridad del código. Además, la gestión de variables de entorno ha presentado dificultades. A diferencia del estándar en Node.js, donde process.env refleja con fidelidad las variables definidas en tiempo de ejecución, en Next.
js este comportamiento se ve alterado por la sobreescritura que realiza el framework. Esto genera discrepancias entre lo esperado y lo que realmente ocurre en producción, lo cual puede afectar la configuración, despliegue y seguridad de las aplicaciones. Este cúmulo de situaciones ha llevado a una creciente insatisfacción, principalmente entre equipos con experiencia que requieren soluciones escalables, predecibles y fácilmente mantenibles. Muchos desarrolladores señalan que, aunque Next.js puede resultar adecuado para proyectos pequeños, prototipos o sitios sencillos, no es la opción óptima para sistemas complejos o aplicaciones empresariales que demandan robustez y estabilidad a largo plazo.
A nivel más general, esta dinámica también podría entenderse como parte del ciclo natural de adopción tecnológica. Inicialmente, cuando nuevas herramientas entran en el mercado, se promueven con entusiasmo y un fuerte impulso comercial, lo que atrae sobre todo a usuarios menos experimentados que valoran la rapidez para alcanzar resultados visibles. Con el tiempo, a medida que la base de usuarios madura y los casos de uso se vuelven más exigentes, emergen las verdaderas pruebas para la tecnología, y las limitaciones inherentes salen a la luz. Esto desencadena una fase de crítica más aguda y reflexiva dentro de la comunidad técnica. No menos importante es la cuestión de la dependencia del ecosistema Vercel y la sensación de vendor lock-in que experimentan algunos usuarios.
Aunque Next.js es de código abierto, su estrecheza con Vercel como plataforma de despliegue y optimización ha generado preocupaciones sobre la libertad de elección y el control total del entorno. Esta percepción incide en la valoración global del framework y motiva en ocasiones movimientos hacia alternativas consideradas menos restrictivas. Por otro lado, la explosión de la popularidad de Next.js ha sido impulsada también por un marketing agresivo y una comunidad creciente de influencers y blogs.
Este fenómeno, aunque positivo en términos de difusión, ha generado cierta saturación y expectativas desmesuradas que no siempre se corresponden con la experiencia real del desarrollo. Frente a este escenario, surgen diversas reflexiones para aquellos que planean elegir un framework para sus proyectos. La elección debe ser consciente y basada en las necesidades reales, el tipo de proyecto y la experiencia del equipo, evitando la trampa de dejarse llevar únicamente por la moda o la promesa de aceleración inicial. Elegir la herramienta adecuada es fundamental para minimizar riesgos futuros y optimizar recursos. En síntesis, la reciente oleada de críticas hacia Next.
js refleja una maduración del ecosistema tecnológico y una revisión más rigurosa de sus características y limitaciones. No implica un rechazo absoluto ni el fin de su utilidad, pero sí invita a una mirada más crítica y equilibrada. Next.js continúa siendo una opción válida y potente para muchos casos, pero su adopción en contextos complejos o de larga duración debe evaluarse con cautela y conocimiento profundo de sus ventajas y posibles desafíos. A medida que el desarrollo web sigue evolucionando, también lo harán las herramientas que lo soportan.
Es probable que Next.js continúe adaptándose para superar estas críticas y mejorar su propuesta, así como que surjan nuevas tecnologías que compitan por liderar la escena. Mientras tanto, la comunidad seguirá aportando experiencias, soluciones y debates que permitirán afinar la elección tecnológica y fomentar mejores prácticas en el desarrollo web moderno.
