Symfony et Laravel font partie des frameworks les plus populaires du marché. Tandis que Symfony domine dans les pays francophones, Laravel est souvent cité en tête de liste dans les classements anglophones. Cette différence culturelle s’explique bien sûr par l’origine française du produit de SensioLabs.
Laravel reste très inspiré de Symfony, utilisant tout de même 11 de ses composants. On connaît bien l’habitude des états-uniens, de réadapter les produits étrangers qui fonctionnent bien pour se les approprier dans leur contexte culturel, cela s’exprime aussi bien dans la tech qu’au cinéma.
Alors, malgré les nombreux points communs entre ces deux frameworks, l’un s’appuyant sur l’autre, quelles sont les principales différences ?
L’accessibilité du container
- Le Service Container de Laravel permet de gérer les dépendances de classes et les injections de dépendances sans aucune configuration. Un simple type-hint est suffisant et tout est géré automatiquement en arrière-plan
- Dans Symfony, il est possible d’obtenir un résultat similaire avec autowire et autoconfigure
Twig et Blade
Pour le templating, Symfony utilise Twig et Laravel utilise Blade, bien qu’il soit facile d’utiliser Twig avec Laravel grâce à TwigBridge.
- La syntaxe de Blade n’est qu’une version plus simple et explicite du php, cela signifie que tout ce qu’il est possible de faire en php est également possible avec Blade. Cela offre une grande souplesse mais a l’inconvénient de permettre beaucoup plus de mauvaises pratiques
- Twig est plus cadré mais ses limites ne sont pas un frein. Elles obligent dans une certaine mesure à respecter les bonnes pratiques
Par exemple, en termes de sécurité, comme Blade n’est pas différent du php, il est plus facile d’échapper proprement aux variables. Le défaut c’est que le moteur n’impose aucune restriction. De l’autre côté, comme Twig fonctionne dans un contexte séparé, tous les appels de fonction et filtres sont limités par les fonctions explicitement déclarées.
Autre exemple, Blade rend possible des requêtes en base de données.
En dehors de ça, les deux moteurs de template sont similaires.
Par exemple, l’héritage de templates et l’import de section sont identiques à l’exception de la syntaxe :
Doctrine et Eloquent
Eloquent utilise le pattern Active Record où le modèle est à la fois la représentation de la base de données et l’endroit où sont effectuées les opérations. Quand Doctrine, lui passe par un Entity Manager où les entités sont des représentations des tables en base de données.
En ce sens, Eloquent demande moins de lignes de code pour fonctionner et est plus facile à appréhender.
Toutefois, dans la pratique, les deux systèmes se ressemblent beaucoup, surtout avec les évolutions de l’Entity Manager qui le font parfois ressembler au Query Builder d’Eloquent.
Il fut un temps où seule Doctrine possédait un système de migration mais désormais Eloquent en a également un, très similaire mise à part la syntaxe.
FormBuilder vs FormRequest
Là ou Symfony dispose de FormBuilder qui permet de générer des formulaires de bout en bout, Laravel n’a pas de système équivalent. Les formulaires doivent être manuellement déclarés dans Blade. Cependant, il dispose de FormRequest qui permet de gérer tout ce qui concerne la validation du formulaire à part et en amont du controller.
Profiler
Contrairement à Symfony, Laravel ne propose pas nativement de Profiler, même s’il existe divers packages pour pallier ce manque, comme Telescope et Laravel DebugBar.
Temps d’apprentissage
Symfony est un gros framework relativement strict qui semble avoir tout prévu avec sa foule de composants par défaut, ce qui est un avantage indéniable mais le rend plus difficile d’accès pour les personnes qui ne sont pas habituées à utiliser des frameworks. Pour le dire autrement, la courbe d’apprentissage est raide.
Laravel est plus permissif, avec tous les défauts que cela inclut. Mais aussi plus simple, avec moins de choses nativement présentes et se limitant presque à une architecture MVC de base. Cela le rend plus accessible et facile à appréhender pour la ou le débutant(e).
Lumen et Silex
Laravel et Symfony possèdent tous les deux leur équivalent sous forme de micro-framework, respectivement Lumen et Silex.
Lumen semble plus spécialisé que Silex. Il se concentre sur le développement de micro-services et d’APIs en privilégiant la vitesse d’exécution. Silex était plus généraliste. Il n’est plus maintenu depuis juin 2018, car depuis, Symfony est plus granulaire et peut être mis en place de manière aussi minimaliste que ce que l’était Silex.
Cache
Laravel n’a pas d’équivalent à HTTP Cache de Symfony. Pour Redis ou Memcached, dans Symfony, il suffit de les déclarer dans les services pour pouvoir les utiliser. Laravel de son côté propose une API Unifiée permettant de faire appel à Redis, Memcached ou encore DynamoDB.
Communauté
En comparant les recherches sur Google Trends, ce qui donne une indication, on constate que Laravel est très loin devant Symfony à l’international. En France c’est l’inverse, Symfony est largement dominant. Pour d’autres pays francophones comme la Belgique, la Suisse ou le Québec, l’écart est moins marqué mais Laravel conserve sa place prédominante. Une ou un développeur avec un bon niveau d’anglais trouvera une communauté plus large que pour Symfony, mais ce dernier a l’avantage d’être très accessible en langue française avec une communauté certes plus réduite mais très active.
Conclusion
Malgré les quelques points de divergence listés ici, les deux frameworks ont plus de points communs que de différences.
À compétence égale des équipes, sur la plupart des projets l’un ou l’autre pourront être utilisés indifféremment sans trop de conséquences.