Cuándo no usar Next.js

Construimos en un solo framework y no aceptamos trabajo fuera de él. Eso hace que esta sea la página de este sitio que deberías leer con más escepticismo, y también la que más merece existir: una empresa que no sabe decir dónde falla su herramienta está describiendo un producto, no una opinión.

Cinco casos. En todos te lo diríamos en lugar de aceptar el proyecto.

1. Un sitio de contenido sin aplicación dentro

Un sitio corporativo, una documentación, una web de marketing con blog. Si nada en él es interactivo más allá de un formulario de contacto y un menú, Next.js es mucha maquinaria para servir HTML.

Astro, Eleventy o Hugo producen lo mismo con una fracción del JavaScript y un build que puedes explicarle a cualquiera. El modelo de componentes de React empieza a rentar cuando hay estado que gestionar y comportamiento compartido que reutilizar. Por debajo de esa línea es coste que mantienes para siempre.

El contraargumento honesto: si el sitio es una parte de un producto que ya usa React, tener un framework para ambos vale algo. Es una razón organizativa, no técnica, y sigue siendo una razón real.

Detrás de esto hay un número, no una sensación. Una ruta de Next.js envía el runtime de React y del App Router, lo use la página o no: en esta web, que no envía código de cliente propio en ninguna ruta, ese suelo son unos 186 KB comprimidos. Una página equivalente en Astro no envía nada hasta que pides algo. Si la página no tiene interactividad que justifique el runtime, estás pagándolo en cada primera visita por un modelo de componentes que no usas. La comparación completa gira sobre una pregunta: qué proporción de tu página tiene que hacer algo después de cargar.

2. El equipo no escribe React

Este es el punto que menos gusta decir en voz alta.

Un framework que dominas gana a uno mejor que estás aprendiendo, en cualquier proyecto con fecha. Un equipo que entrega Laravel, Rails o Django con soltura hará una aplicación mejor en esas herramientas que una aplicación Next.js competente construida mientras se lee la documentación, y la mantendrá durante años sin un especialista.

Elegir Next.js también es elegir su ritmo de cambio. El App Router, los Server Components y el modelo de caché se han movido bastante en tres años, y la 16 volvió a mover middleware, Turbopack y los valores por defecto de imágenes. Ese ritmo es manejable con alguien que lo siga, y caro sin él.

La pregunta no es si tu equipo puede aprenderlo. Es quién lee las notas de versión dentro de dieciocho meses, cuando la persona que estaba entusiasmada con ello ya se ha ido. Si la respuesta es nadie, el framework se quedará sin mantenimiento dentro de tu propia base de código mientras sigue activamente mantenido fuera de ella, que es lo peor de ambos mundos.

3. Todo lo interesante está en el backend

Un motor de pagos, un pipeline de datos, un sistema de planificación, una API con una docena de consumidores. Next.js tiene route handlers y Server Actions, y son buenos en lo suyo, que es servir un front end. No sustituyen a un servidor de aplicaciones.

Si la complejidad del sistema vive en colas, workers, trabajos de larga duración, transacciones entre servicios o cualquier cosa que deba sobrevivir a un despliegue a medio camino, quieres un framework de backend y un ejecutor de trabajos de verdad. Next.js puede entonces ser el front end que habla con él, que es un arreglo perfectamente bueno y un proyecto muy distinto de «lo hicimos en Next.js».

Conviene nombrar la carencia concreta, porque es lo que los equipos descubren tarde: no hay un worker supervisado en el framework. Nada es dueño de un trabajo que falla a las tres de la madrugada, lo reintenta con backoff y lo sigue sosteniendo cuando termina el despliegue. Puedes montar eso alrededor de Next.js con un servicio de colas y un proceso aparte, y en ese momento tienes un backend; así que la versión honesta de la decisión es si quieres elegir uno deliberadamente o llegar a uno por accidente. Contra Laravel y contra Express son el mismo argumento desde dos direcciones.

4. Necesitas el edge y no puedes tenerlo

Next.js se ha movido hacia Node para el trabajo en tiempo de petición. En la 16, la convención proxy que sustituye a middleware corre en Node y el runtime no es configurable.

Si tu arquitectura depende de ejecutar lógica en cien ubicaciones edge

• geo-routing a escala, comprobaciones de autenticación que no deben tocar un origen, moldear peticiones para una audiencia global -, conviene contrastarlo con la dirección actual del framework en lugar de darlo por hecho. Puede que una plataforma edge dedicada encaje mejor que un framework que está restando peso a esa parte.

Este es el punto menos estable de la lista, y preferimos decirlo antes que dejar que se lea como algo permanente. Describe hacia dónde se dirige el framework ahora mismo. Si la ejecución en el edge es central en tu arquitectura, verifícala contra la versión que estás a punto de adoptar y no contra esta página.

5. Un único widget interactivo en la web de otro

Una calculadora de precios metida en una página de WordPress. Un formulario de reservas incrustado en un CMS que no controlas. Next.js es un framework para ser dueño de un sitio entero; si eres dueño de un <div>, entrega un bundle pequeño - JavaScript plano, Preact, un web component - y sáltate el enrutado, el modelo de renderizado y el objetivo de despliegue por completo.

Cómo saber en cuál de los casos estás

Tres preguntas, en este orden. El orden importa porque la primera descarta más proyectos que las otras dos juntas.

1. ¿Qué proporción de la página sigue haciendo algo después de cargar? Casi nada, y la respuesta es un generador de sitios estáticos, no un framework de React.
2. ¿Dónde vive de verdad la dificultad del proyecto? Si vive en trabajos en segundo plano, transacciones e integraciones y no en el camino de renderizado, elige primero el framework de backend y trata el front end como una segunda decisión.
3. ¿De quién es esto dentro de dieciocho meses? No quién lo construye. Quién lo actualiza.

La segunda es la que los equipos responden demasiado deprisa, porque una integración parece una llamada fetch hasta que está construida. Dónde se ejecutan de verdad sus piezas merece leerse antes de decidir que el frontend puede sostenerlas todas.

Si estás eligiendo entre dos cosas concretas en lugar de hacerte la pregunta general, la comparación suele ser más útil que esta página: contra Astro si la duda es cuánto JavaScript debería enviar un sitio de contenido, contra Remix si ya has decidido que quieres un framework de React, contra Laravel si detrás de la aplicación hay un back office de verdad, y contra Express si lo que estás construyendo en realidad es una API.

Dónde sí es la respuesta correcta

Por completitud, porque la lista anterior no es un argumento contra el framework:

• Una aplicación con una superficie pública e indexable y otra autenticada. Renderizar bien ambas desde una sola base de código es lo que hace Next.js y las alternativas en general no.
• Comercio electrónico, donde el catálogo debe ser estático y rápido y el carrito no.
• Cualquier caso en el que los Core Web Vitals sean una cifra comercial y no un marcador, y en el que necesites control del render path para moverla.

Si no tienes claro de qué lado de esa línea estás, esa pregunta tiene una respuesta barata: una auditoría de alcance cerrado que diga qué te está costando el stack, incluida la posibilidad de que la respuesta sea «nada, está bien así».

Uno de esos casos merece página propia, porque es el más habitual de todos: un sitio que ya está en WordPress y funciona. Esa comparación está aquí, y dedica la mayor parte de su extensión a argumentar en contra del cambio.