Next.js vs Laravel: dos preguntas distintas

Esta comparación se plantea como una discusión de lenguajes y no lo es. Los dos están construidos alrededor de centros de gravedad distintos, y la pregunta útil es dónde reside realmente la dificultad de tu aplicación.

En qué es bueno cada uno, sin marketing

Laravel es un servidor de aplicaciones con todo incluido. Colas, tareas programadas, un ORM maduro, migraciones, un sistema de autenticación, una capa de permisos, correo, eventos, un worker de colas que de verdad puedes operar y un ecosistema de administración. Si la parte difícil de tu aplicación es lógica de negocio que debe ejecutarse de forma fiable, el primer día ya tienes casi todo.

Next.js es un framework de renderizado que alcanza una base de datos. Su fuerza es el render path: qué se genera en el build, qué se transmite en streaming, qué descarga el navegador y qué tan rápida es una página para alguien que nunca ha entrado. Si la parte difícil es una superficie pública que debe ser rápida e indexable, está hecho para eso.

La prueba que lo decide

Pregúntate qué rompe tu proyecto si se hace mal.

Si la respuesta es un trabajo en segundo plano, una transacción, una condición de carrera, un flujo con estados o una integración que no puede perder un mensaje, ese es el terreno de Laravel. Next.js tiene route handlers y Server Actions, y son realmente buenos en lo suyo, que es servir un front end. No son un ejecutor de trabajos. No hay en el framework equivalente a un worker de colas supervisado, y construir uno alrededor es trabajo que no tenías previsto.

Si la respuesta es un primer pintado lento, una página que no posiciona, un bundle que cuesta cuatro segundos a los usuarios móviles, o un catálogo que debe ser estático y un carrito que no, ese es el terreno de Next.js, y el Blade renderizado en servidor de Laravel necesitará una historia de front end añadida para competir.

Laravel con Inertia, que es la comparación real

La mayoría de los equipos que sopesan esto están sopesando en realidad Laravel + Inertia + React frente a Next.js + una API. Es una pelea más justa y se reduce a una cosa: si tus páginas necesitan prerenderizarse.

Inertia renderiza en cada petición, siempre. Eso está bien detrás de un login, donde nada es cacheable y nada necesita posicionar. Es una limitación real para un catálogo público, una documentación o una superficie de marketing, donde generar en el build y servir desde un nodo edge es toda la historia del rendimiento.

Entonces:

• Casi todo detrás de un login → Laravel e Inertia te llevarán antes y serán más fáciles de operar.
• Una superficie pública e indexable significativa → Next.js, con Laravel detrás si la lógica de negocio lo justifica.

El arreglo que funciona bien

Laravel como API, administración y ejecutor de trabajos. Next.js como front end público, hablando con él por HTTP.

El coste es un segundo objetivo de despliegue y un contrato entre ambos que alguien tiene que mantener. El beneficio es que cada lado hace aquello en lo que es bueno, y ninguno se estira hacia un papel para el que no fue diseñado. En la práctica, esto es lo que deberían haber sido muchos proyectos de «lo reconstruimos en Next.js».

Cuando ya existe una aplicación Laravel que funciona y el problema es solo el front end, ese es un proyecto más acotado que una reescritura, y a menudo mucho más barato.

Si la respuesta honesta es que tu proyecto no tiene una superficie pública que merezca optimizarse, puede que Next.js no pinte nada en él.