Por qué seguimos eligiendo Laravel en 2026

Elegir un framework en 2026 es sobre todo una decisión de mantenimiento disfrazada de decisión técnica. El código se escribe una vez y se lee durante años, casi siempre por alguien que no estaba cuando se tomaron las decisiones. Esa es la lente que merece la pena aplicar.

El caso es la coherencia, no las funcionalidades

Cualquier ecosistema maduro puede hacer colas, trabajos programados, autenticación, correo, almacenamiento de archivos, migraciones de base de datos y una suite de tests. La diferencia es si llegan como un sistema diseñado junto o como una docena de paquetes que cada uno tomó sus propias decisiones.

Laravel te da lo primero. Un trabajo en cola, un comando programado y un mailable parecen el mismo código, usan el mismo contenedor y se testean igual. Cambiar el driver de cola de base de datos a Redis es un cambio de configuración, no una reescritura.

Esa coherencia tiene un efecto compuesto que los benchmarks no capturan: un ingeniero que abre una aplicación Laravel desconocida ya sabe dónde están las rutas, cómo se expresa la validación y qué hace un service provider. En un proyecto de una o dos personas y cinco años de vida, ese es el factor de coste dominante.

Qué ha cambiado en los últimos años

Dos cosas que vale la pena nombrar, porque las objeciones a PHP suelen tener una década.

PHP 8 es de verdad rápido. Propiedades tipadas, enums, clases readonly, promoción de constructor y un JIT real. Un código PHP moderno se lee como un lenguaje tipado moderno, y el runtime es competitivo para trabajo web acotado por I/O, que es casi todo el trabajo web.

La interactividad dirigida por el servidor mejoró de verdad. Livewire, Hotwire y htmx aterrizaron en la misma idea: la mayor parte de la UI “interactiva” es un formulario, un filtro, un modal o una lista, y publicar un framework de cliente para eso es un mal intercambio. Mantener el estado en el servidor significa un lenguaje para la lógica de negocio y un solo sitio donde viven la validación y la autorización.

Usamos Livewire de forma selectiva, no en todas partes. Este sitio es el ejemplo: las páginas de marketing son plantillas renderizadas en servidor con unos pocos kilobytes de Alpine para la navegación, y solo el formulario de contacto carga un runtime de componentes. Una página sin estado no gana nada con un framework de componentes y lo paga en payload.

En qué Laravel es peor

Un argumento honesto necesita esta parte.

Conexiones de larga duración. El modelo petición-respuesta no es donde quiere vivir un producto cargado de WebSockets. Laravel tiene respuestas sólidas (Reverb, Octane), pero si la presencia, los cursores y la colaboración en vivo son el producto, un runtime construido alrededor de conexiones persistentes sale delante.

Trabajo acotado por CPU. Procesado de imagen y vídeo, cálculo numérico, cualquier cosa para la que irías a una librería nativa. Empújalo a una cola y un worker dedicado, o escribe esa parte en otra cosa. El framework no es la herramienta correcta, y fingir lo contrario acaba mal.

Las convenciones propias del ecosistema. Las facades y los métodos mágicos permiten escribir rápido y dan peor análisis estático que un equivalente cableado de forma explícita. Es un intercambio real. Lo mitigamos con firmas tipadas y PHPStan, no fingiendo que no existe.

Expectativas de frontend. Si el diseño pide un cliente de verdad tipo app (soporte offline, actualizaciones optimistas en todas partes, estado complejo en el cliente) un enfoque dirigido por el servidor te pelea. Usa la herramienta correcta.

Dónde elegiríamos distinto

• Un editor colaborativo en tiempo real: algo construido alrededor de conexiones persistentes.
• Un pipeline de machine learning: Python, donde viven las librerías.
• Un servicio de ingesta de eventos de alto throughput: Go, y que sea aburrido.
• Un sitio de contenido estático sin aplicación detrás: un generador de sitios estáticos, y ningún servidor.

Ninguno de esos es tanto una debilidad de Laravel como el hecho de que Laravel no es una respuesta universal.

El criterio de verdad

Para las aplicaciones que nos suelen pedir (un proceso de negocio con una base de datos detrás, integraciones con servicios que el cliente ya paga, unos pocos miles de usuarios, y una vida esperada de diez años) la pregunta no es qué stack tiene el techo más alto. Es qué stack puede seguir trabajando un mantenedor competente en 2032 sin una fase de arqueología.

Las convenciones, la documentación y la disciplina de actualización de Laravel hacen eso probable. Es una razón aburrida para elegir un framework, y es la que se ha sostenido.