Laravel vs Symfony: elegir entre los dos y lo que cuesta

Esta comparación suele presentarse como un test de personalidad: Laravel es pragmático, Symfony es riguroso, elija el que suene a usted. Eso no sirve cuando hay un presupuesto de por medio.

La diferencia real es esta: Symfony da por hecho que usted decidirá, y Laravel ya ha decidido. Todo lo demás se sigue de ahí, en las dos direcciones.

Qué compra y qué cuesta que lo decidan por usted

En Laravel, el ORM, la abstracción de colas, la capa de correo, el andamiaje de pruebas, el scaffolding de autenticación y el sistema de validación están elegidos. Puede sustituirlos, y casi nadie lo hace. Quien entra en un proyecto Laravel sabe dónde están las cosas antes de abrir el repositorio.

En Symfony, la mayoría de eso son elecciones: Doctrine es lo convencional pero no obligatorio, y al framework no le incomoda que usted ensamble otra cosa. El coste es una decisión por proyecto. El beneficio es que cuando sus requisitos son de verdad inusuales, nada le está peleando.

Los dos modos de fallo son simétricos y los dos son reales. Una aplicación Laravel cuyo dominio nunca encajó con las suposiciones del framework acaba siendo mucho código trabajando alrededor de Eloquent. Una aplicación Symfony donde nadie impuso convenciones acaba con tres equipos que han resuelto el mismo problema de tres formas.

El ORM es la mayor diferencia individual

Aquí vive casi toda la divergencia del día a día.

Eloquent es active record: el modelo es la fila y sabe guardarse a sí mismo. Se escribe rápido y se lee bien - $order->customer->name es obvio para cualquiera. El coste es que la persistencia se reparte por sus objetos de dominio, y que la comodidad hace fáciles de escribir sin notarlo las consultas N+1.

Doctrine es data mapper: las entidades son objetos planos que no saben nada de la base de datos, y una capa aparte calcula qué cambió. Mantiene la persistencia fuera del dominio, que es exactamente lo que quiere cuando el dominio es complicado. Cuesta un entity manager, una unidad de trabajo que hay que entender, y más ceremonia para el noventa por ciento de casos que eran simples.

Si su aplicación es sobre todo CRUD sobre un esquema relacional, active record es menos código para el mismo resultado. Si su dominio tiene invariantes que no deben depender de cómo se guardan las filas, el mapper se gana su sobrecoste. Esa es la división honesta, y se corresponde con la elección de framework más que ninguna otra cosa.

Dónde cada uno es una respuesta clara

Laravel, claramente: un equipo de producto entregando funcionalidades de forma continua; una aplicación SaaS; cualquier cosa donde se quieran la cola, el planificador, el correo y el broadcasting y prefiera no integrar cuatro bibliotecas; un equipo que crecerá contratando, porque el mercado es mayor y la incorporación más corta.

Symfony, claramente: un sistema de vida larga en un dominio con complejidad real - seguros, logística, finanzas reguladas - donde el modelado importa más que la velocidad de entrega; una organización que ya opera Symfony; un proyecto donde el framework tiene que sentarse al borde de una arquitectura existente en lugar de definirla.

Cualquiera, honestamente: casi todo lo demás. Un equipo con experiencia escribe una aplicación mantenible en los dos, y la diferencia en el resultado será menor que la que marca si alguien escribió pruebas.

Lo que lo decide en la práctica

No la arquitectura. Las personas.

El mercado de Laravel es bastante mayor, y el de Symfony se inclina hacia perfiles más senior, que o es lo que quiere o es lo que no se puede permitir. Un equipo que ya conoce uno de los dos entregará más rápido en ese que en el teóricamente mejor encaje, y la distancia es mayor que cualquier ventaja arquitectónica.

El segundo factor práctico es el mercado de agencias y soporte. Hay más empresas dispuestas a hacerse cargo de un código Laravel, y eso importa el día en que se va la gente que lo construyó. No es un argumento sobre calidad. Es un argumento sobre qué le pasa a la aplicación en el cuarto año.

Lo que no lo decide

El rendimiento. Los dos pasan su tiempo en su base de datos. Si su aplicación es lenta, lo es por razones que sobrevivirán intactas a un cambio de framework.

La "preparación empresarial". Los dos se usan en sistemas grandes con dinero real encima. Las aplicaciones que fallan a escala fallan por un esquema, por una cola que nadie vigiló o por la ausencia de pruebas, en cualquiera de los dos.

Las ventanas de soporte largo. Las versiones LTS de Symfony duran más, y esa es una diferencia real de planificación. Importa si su organización no puede actualizar cada año, y si eso es cierto, lo que hay que arreglar es la razón por la que no puede, porque esa restricción le costará más de lo que la elección de framework podría costarle jamás.

Si ya tiene uno de los dos

Quédeselo. Casi todas las peticiones que recibimos para pasar de uno a otro son en realidad peticiones para arreglar algo que no causaba el framework: una aplicación que nadie puede cambiar con seguridad, o una versión fuera de soporte. Las dos cosas se abordan dentro del framework que ya tiene, por una fracción del presupuesto, y la migración no las habría arreglado.

Si la lista corta no es realmente Laravel y Symfony sino Laravel y algo fuera de PHP, Rails es el equivalente más cercano. Y si la duda es si un framework de esta forma encaja con el proyecto, esa es la página más general.