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.

Qué reconstruyes en cada dirección

La forma honesta de ponerle precio a esta decisión es listar lo que el otro lado te regala.

Eligiendo solo Next.js, reconstruyes: autenticación y sesiones, un modelo de permisos, una interfaz de administración para la gente que lleva el negocio, un ejecutor de trabajos y algo que lo planifique, correo transaccional, y migraciones de base de datos. Todo eso existe como librería. Ninguna es una decisión en la que esperabas gastar una semana, y ensamblar seis librerías produce un stack que nunca se ha probado como conjunto.

Eligiendo solo Laravel, reconstruyes: el camino de renderizado. Generación en tiempo de build, revalidación incremental, un bundle de cliente que controlas, streaming y tratamiento de imágenes. Parte de eso tiene respuestas del lado de Laravel y parte no, y las que no son precisamente las que aparecen en los Core Web Vitals.

Ninguna de las dos listas es un argumento por sí sola. Son la factura, y deberías leer la que sea más larga para tu proyecto.

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.

La pregunta del equipo, que decide más de estos casos que la arquitectura

Si tienes ingenieros de PHP y ninguno de React, el argumento arquitectónico de arriba vale menos de lo que parece. Un framework en el que tu equipo es fluido gana a uno mejor que está aprendiendo, y el coste de mantenimiento de la segunda opción cae sobre quien siga ahí dentro de dos años.

Lo contrario también se cumple, y se dice menos: un equipo de JavaScript que adopta Laravel porque un artículo se lo recomendó operará mal el worker de colas, y un worker de colas mal operado es peor que no tener ninguno.

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

Dos cosas hacen que este arreglo funcione en lugar de solo existir. El contrato tiene que generarse y no describirse: un cliente tipado producido desde el propio esquema de la API, de modo que un cambio en un lado rompa un build en el otro en vez de una página en producción. Y la autenticación tiene que tener un único dueño, con el front end sosteniendo una sesión que le han dado en lugar de una segunda implementación de las mismas reglas.

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.