Descargo de responsabilidad: desarrollé extensamente en Laravel 5.1+ y Symfony 2.3+.
Laravel se centra en la simplicidad y en la entrega de valor, incluso si no es un desarrollador avanzado. Como tal, proporciona lo siguiente:
- Una estructura integral : tiene casi todo listo en la edición estándar con algunos ejemplos ficticios: migraciones, modelos, servicios, controladores, comandos … Pero para ser justos, Symfony Standard Edition también lo tiene.
- Migraciones extremadamente fáciles de escribir (configuradas de fábrica), crear un nuevo modelo y requerirlo es cuestión de unas pocas líneas (inexistente en Symfony SE)
- Amplia generación de código (tiene un comando para casi todo). Esta es principalmente una plantilla de caldera, no muy útil, pero bienvenida cuando eres novato y no sabes dónde poner qué. También tiene uno bastante avanzado en Symfony SE, pero más específico, es decir, para generar una entidad y su CRUD. En Laravel tienes generación de código para casi todo, incluso si hace poco.
- Integración frontal : Gulp, Elexir y VueJ listos para usar. En Symfony SE, no tienes mucho de este lado, esta es una gran victoria para Laravel cuando comienzas como un novato y no te sientes cómodo con el front-end.
Además tiene algunas defensas filosóficas:
- Convención sobre configuración: esto significa que muchas cosas se han simplificado en el marco porque suponía una forma de hacer las cosas. Intente ir de otra manera, será más difícil que si el marco estuviera más orientado a la configuración (aunque todavía es factible). Para extender un poco sobre ese punto: algunas cosas son fáciles de cambiar a través de la configuración, a saber, todo lo relacionado con las variables de entorno (a través de
.env ), los archivos de configuración o la configuración Eloquent ORM son fáciles. Pero para cambios más profundos como la estructura del archivo, debe extender la clase de aplicación Laravel y anular algunos valores codificados. A veces los cambios son más profundos que eso: en algunos comandos o compilador de caché. Básicamente todavía es factible, pero debe asegurarse de verificar todo el uso codificado, extender cada clase y anular el registro para usar su clase en lugar de la nativa. Si también desea cambiar el modo de depuración para que sea configurable a nivel de aplicación (es decir, tener dos modos de depuración diferentes para su aplicación, por ejemplo, tener un controlador frontal normal y un controlador frontal de desarrollo), también es mucho más problemático, tienes que cambiar el proceso de arranque y el proveedor de depuración.
- Cableado automático : el Contenedor de inyección de dependencia lo utiliza mucho para ofrecer al usuario la posibilidad de hacer lo menos posible para crear servicios.
- Fachada : facilita el acceso estático a un servicio y evita la inyección de dependencia.
- Blade : su característica principal es su falta de características: tiene algunas cosas como si / sino / a menos que bloquee y pueda acceder estáticamente a sus servicios, pero eso es casi todo
- Alias : poder reducir el nombre de los espacios de nombres mediante alias
- Tipografía de pato : debido al uso de alias y fachada, no espere mucha ayuda de su IDE para la autocompletación o validación de herramientas de análisis estático como el escrutinizador. A algunas personas no les importa, porque la escritura de patos te ofrece más flexibilidad.
Tenga en cuenta que solo mencioné algunas características, me abstuve de comentar lo que pienso al respecto. En realidad, algunos de ellos son muy controvertidos y se anuncian cada vez menos (como Facade y Aliases). Pero entiende lo esencial: mantener las cosas simples, incluso si eso significa hinchar las cosas detrás del capó (por ejemplo, la clase base del modelo Eloquent es 3K LoC) y tomar algunas decisiones al respecto.
Si no está familiarizado con los marcos o viene más de un fondo Ruby, Laravel es una buena opción, ya que puede ayudarlo a producir cosas rápidamente sin mucho conocimiento de OOP.
Sin embargo, Symfony es una bestia muy diferente. Pero antes de aclarar algunas cosas. Cuando estás hablando de Symfony, puedes estar hablando de 3 cosas diferentes:
- Componentes de Symfony : bibliotecas PHP simples, reutilizables en todas partes. Laravel es en realidad más del 50% (en términos de dependencias del paquete de producción) basado en componentes de Symfony. Laravel tiene algunos componentes, a saber, ORM elocuente, pero no todos están destinados a ser reutilizables. Por ejemplo, el famoso iluminar / soporte es cualquier cosa menos reutilizable, es una biblioteca de utilidad de 11K LoC, esta es una dependencia muy muy grande. Otro inconveniente de los componentes de Laravel es que, como el marco en sí, no son semver. Esto es muy complicado ya que en PHP, la mayoría de las bibliotecas son semver y a menudo tiendes a asumir que todo lo es.
- FrameworkBundle : el núcleo del marco de Symfony que es el pegamento entre los componentes. Proporciona:
- Un contenedor de inyección de dependencia extremadamente potente (muy diferente al de Laravel, pero volveré a usarlo más adelante)
- Un sistema de configuración: tanto para su aplicación como para aplicaciones de terceros.
Symfony Standard Edition : la aplicación predeterminada de Symfony. Básicamente es el FrameworkBundle con casi todos los componentes de Symfony y algunas otras bibliotecas para proporcionar una configuración que debería adaptarse a casi todos los casos de uso. Es con lo que puedes comparar el valor predeterminado de Laravel. Lumen es otra variante.
En términos de facilidad, Symfony te permite ir muy rápido si no más rápido que en Laravel. Puede aprovechar algunas convenciones para evitar una gran cantidad de código adicional. Pero como solía apuntar a desarrolladores más avanzados y estar más basado en la configuración, durante mucho tiempo solía ser mucho más difícil comenzar que Laravel. Creo que la brecha allí se cerró mucho, ya que se han hecho muchos esfuerzos para hacer que Symfony sea más accesible, pero estoy seguro de que Symfony podría ser un poco más difícil para empezar.
No, se ha hecho esta distinción, aquí como algunas características que ofrece Symfony:
- Un sistema de configuración : en Laravel, simplemente ingrese sus parámetros de configuración en la carpeta de
config en archivos PHP simples. Esto es bueno para su aplicación, pero ¿qué pasa si desea crear una biblioteca que exponga una configuración a su marco? En Laravel, esto no es factible o al menos el marco no te da ninguna forma de hacerlo. Lo único que puede hacer es crear una configuración predeterminada, pero exponerla y validarla. En Symfony esto es extremadamente fácil y tiene una documentación y una validación del código lista para usar. Además, tiene soporte para archivos PHP, XML y YAML en Symfony, mientras que Laravel solo admite archivos de configuración PHP.
- Contenedor de inyección de dependencia : tiene un cableado automático como en Laravel hasta cierto nivel, pero no completamente. Sin embargo, Symfony le permite ir mucho más lejos en términos de registro de servicios (fábricas, decoradores, etiquetas, servicios abstractos y privados). Para elaborar: como cualquier DIC, Symfony y Laravel uno tiene características comunes: registrar un servicio es fácil en PHP, vincular un alias es básico. Las diferencias son:
- Soporte para PHP, YAML y XML (Laravel solo es compatible con PHP)
- Mejor soporte para fábricas, decoradores (puedes hacerlo en Laravel, pero manualmente)
- El sistema de etiquetado es más avanzado: puede hacer más que solo dar un nombre de etiqueta, sino pasar valores arbitrarios. Por ejemplo, si desea que un registro tome todos los servicios etiquetados en un orden determinado, puede agregar un número de prioridad u ordenar esta lista de etiquetas.
- Mayor optimización del rendimiento: no es que Laravel sea flojo allí, es solo que las dependencias en Laravel se resuelven en tiempo de ejecución, no se puede optimizar como se hace en Symfony.
Para Laravel:
- Autowiring un ciudadano de primera clase. Algo que Laravel DIC tiene más que Symfony en este aspecto es que 1. no necesita registrar ningún servicio en absoluto (en Symfony, aún debe declarar su servicio, y si no tiene que ocuparse de inyectar dependencias, declarar como cableado automático) 2. puede hacer un enlace contextual.
Recursos de traducción : en Laravel nuevamente solo tienes archivos PHP. En Symfony tiene la opción XLF (un estándar de la industria), PHP, YAML. También puede tener traducción para diferentes idiomas fuera de la caja.
Entorno de desarrollo : a diferencia de Laravel, tienes dos controladores frontales en Symfony. Uno para el modo “regular” (depende de lo que configuró su aplicación, generalmente prod), y otro para el modo “dev”. Esto le permite ejecutar su aplicación en dos modos diferentes en paralelo. También, a diferencia de Laravel, en realidad tiene un modo de desarrollo listo para usar, para el que no hay almacenamiento en caché (excepto algunos metadatos, especialmente para Doctrine and Translations si los está usando) porque son lentos como el infierno (lo cual está bien, porque es algo que significa para ser almacenado en caché en primer lugar). En Laravel, nuevamente es algo que requiere mucho trabajo adicional si quieres hacerlo de esa manera.
Formulario y validación : el componente Formulario de Symfony (instalado de forma predeterminada en Symfony Standard Edition). A diferencia de Laravel, donde tiene que crear mensajes de validación, tiene la mayoría de ellos allí, mensajes de validación y sus traducciones.
Configuración avanzada de caché : tienes muy poco que hacer en Laravel, mientras que en Symfony puedes hacer casi lo que quieras.
Comandos de depuración : puede hacer mucho más de lo que tiene en Laravel: enrutamiento, contenedor, configuración, traducción, lo que sea.
Estoy seguro de que me perdí algunas cosas en ambos lados, la gente puede señalarlas y las agregaré o rectificaré si es necesario, pero esto debería darle una buena visión general.
Como puede ver, hay una gran diferencia: Laravel es más obstinado y rubyesco, Symfony es más javaesco y mucho más configurable (el núcleo, FrameworkBundle, es todo lo que necesita para un marco, por eso Symfony puede usarse como un micro -marco, así como un marco completo). A menudo, aquí “Symfony es un nivel más empresarial”, esto se debe principalmente a que:
- Es mucho más fácil “extender” (a diferencia de Laravel, en realidad no tiene que extender clases para agregar o cambiar funcionalidades) y configurable
- Tiene soporte para más herramientas de grado industrial / empresarial (XML es un estándar en muchas grandes empresas, así como XLF)
- Una política dorada de compatibilidad con versiones anteriores: Laravel también tiene LTS pero mucho más corto y, a diferencia de Symfony, Laravel no es semver (y su componente como Eloquent tampoco, urk– Lo siento, esa parte realmente me molesta)
- Puede ir mucho más lejos en términos de optimización: en términos de caché, compilación de clases, registro de servicios
Ahora, por haber usado ambos, prefiero Symfony porque una vez que lo entiendes, es mucho más flexible y fácil de usar. Sin embargo, requiere una buena comprensión de la POO y algunos patrones. Como resultado, siempre será menos accesible que Laravel, aunque se están haciendo enormes esfuerzos para reducirlo. Que algunas preferencias personales (prefiero la escritura estática a la de pato). Si eres un buen desarrollador con un buen conocimiento de OOP, definitivamente puedes hacer lo que quieras con ambos marcos. Al final del día, son herramientas, y es la era del Compositor: necesitas algo, lo necesitas y lo usas.
Editar: Otra cosa que vale la pena señalar, agregaría otra gran diferencia es que Laravel no puede llegar tan lejos como Symfony en términos de optimización por diseño: Symfony tiene pasos de compilación, lo que permite hacer muchas más cosas, como exponer la configuración con validación, servicio definiciones y soporte para diferentes formatos de archivo. Aunque permite hacer más cosas, está claro que puede ser más complejo de tratar.
