Symfony vs. Laravel: ¿qué framework de PHP elegir?

Symfony y Laravel son los fra­me­wo­r­ks PHP más populares. Ambos son productos sólidos y puestos a prueba, cada uno con sus propias ventajas y de­s­ve­n­ta­jas. A co­n­ti­nua­ción, ex­pli­ca­mos cómo funcionan los fra­me­wo­r­ks PHP y para qué proyectos es más adecuado usar Laravel o Symfony.

¿Qué es PHP y qué fra­me­wo­r­ks de PHP existen?

Cuando se lanzó PHP a mediados de la década de 1990, fue el primer lenguaje de pro­gra­ma­ción web dedicado. Las “Personal Home Page Tools”, como se llamaba ini­cia­l­me­n­te este lenguaje, permitía montar un documento HTML di­ná­mi­ca­me­n­te en el servidor de forma sencilla. Veamos qué significa exac­ta­me­n­te esto.

Los do­cu­me­n­tos HTML co­n­s­ti­tu­yen la base de la in­fo­r­ma­ción que se encuentra en la web. El contenido real está es­tru­c­tu­ra­do por etiquetas o tags de HTML. El HTML se vuelve in­te­re­sa­n­te cuando el contenido dinámico se inserta mediante pro­gra­ma­ción en la es­tru­c­tu­ra estática, y PHP fue re­vo­lu­cio­na­rio pre­ci­sa­me­n­te en este aspecto. El lenguaje puede in­cru­s­tar­se en HTML y otros do­cu­me­n­tos de texto. Mientras la es­tru­c­tu­ra estática permanece intacta, la in­fo­r­ma­ción dinámica se añade a través de código insertado entre “etiquetas PHP” es­pe­cia­les. Por ejemplo, el nombre de un usuario puede aparecer en el mensaje de bie­n­ve­ni­da:

<h1>
    Welcome back, <?php echo $user ?>
</h1>

La constante búsqueda de nuevas fu­n­cio­na­li­da­des para las apli­ca­cio­nes web, como la co­ne­c­ti­vi­dad a bases de datos, la au­te­n­ti­ca­ción de usuarios y la va­li­da­ción de fo­r­mu­la­rios, llevó a la aparición de fra­me­wo­r­ks web de PHP. Situados co­n­ce­p­tua­l­me­n­te entre una bi­blio­te­ca de pro­gra­ma­ción y un sistema de gestión de co­n­te­ni­dos, las capas y co­m­po­ne­n­tes que contiene son adecuados para ensamblar sistemas más grandes. Con el paso del tiempo, junto a Laravel y Symfony, también podemos nombrar otros fra­me­wo­r­ks PHP sólidos:

• CakePHP, 2005
• Symfony, 2005
• Co­deI­g­ni­ter, 2006
• Proyecto Laminas, antes Zend Framework, 2006
• Yii, 2008
• Laravel, 2011

Symfony vs. Laravel

Los fra­me­wo­r­ks web PHP Laravel y Symfony tienen mucho en común. Ambos se han de­sa­rro­lla­do como proyectos de código abierto y son adecuados para crear apli­ca­cio­nes web basadas en se­r­vi­do­res. Laravel y Symfony utilizan el patrón “Modelo-Vista-Co­n­tro­la­dor (MVC)” para asegurar la se­pa­ra­ción de los intereses críticos. Las pe­ti­cio­nes a la apli­ca­ción web son pro­ce­sa­das por un co­n­tro­la­dor, que gestiona los datos a través del modelo y los presenta en la vista:

• Modelo: modelo y gestión de datos
• Vista: interfaz de usuario
• Co­n­tro­la­dor: interfaz entre el modelo y la vista

Tanto Symfony como Laravel han co­n­tri­bui­do si­g­ni­fi­ca­ti­va­me­n­te al de­sa­rro­llo del eco­si­s­te­ma PHP. Así, de ambos marcos han surgido im­po­r­ta­n­tes te­c­no­lo­gías basadas en PHP, que también se utilizan en otros proyectos. En pa­r­ti­cu­lar, Symfony es famosa por su es­tru­c­tu­ra modular de co­m­po­ne­n­tes des­aco­pla­dos. Incluso otros fra­me­wo­r­ks PHP, como Yii y Laravel, utilizan co­m­po­ne­n­tes de Symfony.

Composer pro­po­r­cio­na una base sólida para la gestión de paquetes para proyectos PHP en Laravel y Symfony. Además del propio framework, se pueden instalar y gestionar otros co­m­po­ne­n­tes. Composer está di­s­po­ni­ble en todos los sistemas ope­ra­ti­vos de servidor, y ofrece la po­si­bi­li­dad de usar, por ejemplo, PHP Composer en Ubuntu o PHP Composer en los packs de hosting de IONOS.

Aquí, nos referimos a las versiones del framework Laravel 4+ y Symfony 2/3. Las versiones an­te­rio­res tenían una es­tru­c­tu­ra co­m­ple­ta­me­n­te diferente. Veamos las si­guie­n­tes ca­ra­c­te­rí­s­ti­cas de Laravel y Symfony en detalle:

Pla­n­ti­llas en Laravel y Symfony

PHP y su idea de la “plantilla” como un modelo que combina co­m­po­ne­n­tes estáticos y dinámicos fue re­vo­lu­cio­na­ria. An­te­rio­r­me­n­te, todo el código HTML tenía que co­m­bi­nar­se mediante un programa que unía en cadenas las partes estáticas y los valores generados di­ná­mi­ca­me­n­te. Este enfoque era lento y propenso a errores porque era difícil de seguir.

Además de incrustar código en los textos estáticos, los “includes” co­n­tri­bu­ye­ron si­g­ni­fi­ca­ti­va­me­n­te al éxito de PHP. El comando “include” permite ensamblar una página a partir de varias piezas. Esto permite realizar diseños cohe­re­n­tes, como varias páginas con co­n­te­ni­dos di­fe­re­n­tes, pero con el mismo menú de na­ve­ga­ción.

La creación de pla­n­ti­llas consiste en generar do­cu­me­n­tos HTML a partir de pla­n­ti­llas estáticas y co­m­po­ne­n­tes dinámicos. Al utilizar PHP di­re­c­ta­me­n­te como lenguaje de pla­n­ti­llas, aparecen rá­pi­da­me­n­te graves de­s­ve­n­ta­jas, dado que HTML, PHP, SQL, CSS y Ja­va­S­cri­pt pueden mezclarse dentro de un archivo PHP y se da una falta de “se­pa­ra­ción de intereses”, es decir, no se dividen los programas in­te­r­na­me­n­te según sus objetivos o intereses. Además, se pueden generar brechas de seguridad debido a in­ye­c­cio­nes SQL y Cross Site Scripting (XSS).

Para evitar estos efectos negativos, Laravel y Symfony vienen con sus propios lenguajes de pla­n­ti­llas que aceptan datos y re­n­de­ri­zan HTML. Se garantiza una limpia se­pa­ra­ción de intereses; la salida se limpia au­to­má­ti­ca­me­n­te mediante el llamado “escape”, evitando así la inyección de código. Los do­cu­me­n­tos PHP o HTML generados pueden al­ma­ce­nar­se te­m­po­ra­l­me­n­te en caché.

El lenguaje de pla­n­ti­llas de Symfony (“Twig”) permite la creación de familias de do­cu­me­n­tos complejas, in­clu­ye­n­do diseños, parciales y co­m­po­ne­n­tes. Twig contiene muchos filtros y funciones útiles y se basa en una sintaxis fácil de aprender. Creamos di­ná­mi­ca­me­n­te una lista de usuarios:

<h1>Users</h1>
<ul>
    {% for user in users %}
        <li>[ user.name }}</li>
    {% endfor %}
</ul>

Laravel se basa en el lenguaje de pla­n­ti­llas “Blade”, diseñado a medida. A di­fe­re­n­cia de Twig, las pla­n­ti­llas Blade pueden contener cualquier código PHP. Pero, al igual que en Twig, las ex­pre­sio­nes entre dobles corchetes se evalúan y el resultado se emite. El mismo ejemplo en Blade:

<h1>Users</h1>
<ul>
    @foreach ($users as $user)
        <li>{{ $user->id }}</li>
    @endforeach
</ul>

Apli­ca­cio­nes web en Laravel y Symfony

Las pla­n­ti­llas son su­fi­cie­n­tes para páginas web puramente in­fo­r­ma­ti­vas sin fu­n­cio­na­li­dad. Se monta una página en el servidor cuando se abre y se muestra a los vi­si­ta­n­tes, y si se dispone de una capa de caché, ya se tiene una solución pasable. Las apli­ca­cio­nes web, sin embargo, requieren un concepto más amplio.

Una apli­ca­ción web clásica de la “Web 2.0” suele requerir que los usuarios puedan co­ne­c­tar­se, crear y modificar co­n­te­ni­dos. En otras palabras, se necesita una apli­ca­ción de base de datos que permita las ope­ra­cio­nes CRUD más im­po­r­ta­n­tes. Para que esto funcione de manera si­g­ni­fi­ca­ti­va para múltiples usuarios, se necesitan recursos para la au­te­n­ti­ca­ción, la gestión de derechos y la gestión de sesiones.

En principio, PHP contiene los bloques de co­n­s­tru­c­ción ne­ce­sa­rios. El lenguaje pro­po­r­cio­na funciones para acceder a las cookies, gestionar las sesiones y mucho más. También se puede gestionar la conexión a una base de datos, la ejecución de consultas y el acceso a los valores de la petición HTTP. Sin embargo, se utilizan pocas funciones ab­s­tra­c­tas de bajo nivel y variables globales como $_GET, $_POST y $_COOKIE.

En la práctica, los equipos de de­sa­rro­llo tendían a re­in­ve­n­tar re­pe­ti­da­me­n­te las mismas he­rra­mie­n­tas con cada nueva apli­ca­ción web. Esto dio lugar a muchos de­sa­rro­llos internos plagados de lagunas de seguridad y falta de do­cu­me­n­ta­ción. Lo que faltaba era un enfoque es­ta­n­da­ri­za­do o un kit de co­n­s­tru­c­ción sólido que co­n­tu­vie­ra co­m­po­ne­n­tes ne­ce­sa­rios de alta calidad. La co­n­se­cue­n­cia lógica fue la aparición de los fra­me­wo­r­ks de de­sa­rro­llo web.

Un mapeo objeto-re­la­cio­nal (ORM) funciona como una interfaz entre el código orientado a objetos y una base de datos re­la­cio­nal. Una apli­ca­ción web se nutre de las in­ter­ac­cio­nes de los usuarios con datos que cambian con el tiempo. No­r­ma­l­me­n­te, la capa de apli­ca­ción se escribe en un lenguaje de pro­gra­ma­ción orientado a objetos, mientras que la capa de al­ma­ce­na­mie­n­to se crea entorno a una base de datos re­la­cio­nal. En cuanto a Laravel y Symfony, ambos vienen con su propia im­ple­me­n­ta­ción de ORM.

El ORM utilizado en Symfony se llama “Doctrine” y se gestiona como un proyecto in­de­pe­n­die­n­te. Doctrine se basa en el patrón “Data Mapper” y consta de varios co­m­po­ne­n­tes; además del ORM, también hay una capa de caché. El ORM “Eloquent” de Laravel sigue el patrón de “Active Records” y se considera más fácil de usar. Ambos ORM pueden co­ne­c­tar­se a una variedad de backends de bases de datos di­fe­re­n­tes.

App Sca­f­fo­l­di­ng en Laravel y Symfony

Laravel y Symfony tienen su propia interfaz de línea de comandos (CLI) para la gestión de proyectos. La CLI puede uti­li­zar­se, por ejemplo, para el App Sca­f­fo­l­di­ng o “andamiaje de apli­ca­cio­nes”. Se trata de la co­n­s­tru­c­ción au­to­ma­ti­za­da de es­tru­c­tu­ras de proyecto, como co­m­po­ne­n­tes de modelo-vista-co­n­tro­la­dor o modelos de bases de datos.

El CLI de Laravel “artisan” y el comando “bin/console” de Symfony contienen una variedad de comandos útiles. Ló­gi­ca­me­n­te, se requiere una apli­ca­ción Laravel o Symfony antes de poder acceder a la CLI. Para la in­s­ta­la­ción inicial de una apli­ca­ción Laravel o Symfony, se suele utilizar Composer.

Resumen de las ventajas y de­s­ve­n­ta­jas de Laravel y Symfony

Laravel y Symfony son fra­me­wo­r­ks web co­n­so­li­da­dos. Laravel se considera más simple y más adecuado para proyectos pequeños. La curva de apre­n­di­za­je acesible y los re­su­l­ta­dos obtenidos rá­pi­da­me­n­te han co­n­tri­bui­do al éxito de este popular framework PHP.

Symfony es famosa por sus co­m­po­ne­n­tes des­aco­pla­dos. Pueden uti­li­zar­se juntos como un framework web o in­di­vi­dua­l­me­n­te como parte de un software de creación propia. Mientras que Laravel se centra en la si­m­pli­ci­dad, Symfony se esfuerza por la fle­xi­bi­li­dad. Esto hace que el marco sea más adecuado para proyectos complejos con re­qui­si­tos es­pe­cia­les.

A co­n­ti­nua­ción, pre­se­n­ta­mos un resumen de las ventajas y de­s­ve­n­ta­jas en una co­m­pa­ra­ción de Symfony vs. Laravel: