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.

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.

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».

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.

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.

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í».