Sélectionner une page

Laravel vs Symfony : PHP est actuellement en tête du classement des frameworks côté serveur de plus de 79%, Laravel et Symfony étant les choix les plus populaires parmi eux. Dans cet article, nous examinons leurs avantages et leurs inconvénients.

Laravel vs Symfony
Laravel vs Symfony

Si vous envisagez d’utiliser un framework PHP pour votre nouvelle application côté serveur, vous serez probablement confronté à un choix entre les deux leaders actuels du marché, Symfony et Laravel. Puisque Laravel est en fait basé sur Symfony et partage les mêmes composants de base, les avantages distinctifs de chaque framework peuvent être difficiles à comprendre. 

L’idée reçus courante que nous allons examiner, est que Laravel est plus rapide en fonctionnement et plus facile à implémenter au départ, et qu’il dispose d’une documentation en ligne supérieure et d’une courbe d’apprentissage plus conviviale.

Il est mieux adapté aux projets qui nécessitent une mise en œuvre rapide, avec une portée moins complexe ou des exigences d’évolutivité à haut volume. Dans le même temps, Symfony nécessite un engagement initial plus important, mais permet une réutilisation plus efficace du code et la production d’applications Web plus robustes et évolutives au niveau des l’entreprises.

Il n’y a pas d’organisations vraiment neutres qui comparent les implémentations à grande échelle à égalité entre les deux frameworks, de sorte que les comparaisons de performances sont inévitablement anecdotiques. Néanmoins, nous explorerons les mérites de chacun et certaines des différences entre eux en ce qui concerne le développement PHP pour les entreprises.

Pourquoi PHP ?

Le langage de script open-source côté serveur PHP a connu un parcours souvent douloureux vers le sommet depuis sa création en 1994. Avec JavaScript et Flash, il était devenu, au début des années 2000, l’une des technologies Web les plus ridiculisées. Souvent critiqué comme langage «amateur», PHP semblait incapable de s’adapter à sa popularité croissante en termes de sécurité, de performances et de fonctionnalités.

Mais juste au moment où JavaScript est réapparu via JQuery et la disparition de Flash, PHP a finalement réussi à convaincre bon nombre de ses critiques grâce à une collaboration open-source à long terme, une feuille de route audacieuse de versionnage, et le développement et l’adoption à grande échelle et frameworks hautement performants. Parmi ceux-ci se trouvent Laravel, CakePHP, Symfony, Zend Framework, FuelPHP, PHPixie et Phalcon.

Laravel vs Symfony : L’essor du framework PHP

Des frameworks efficaces et riches en fonctionnalités ont donné à PHP un certain nombre de nouvelles capacités et caractéristiques qui s’avéreraient essentielles pour l’adoption à grande échelle et en entreprise. Les avantages comprennent :

  • la disponibilité accrue des développeurs qui résulte d’une adoption à grande échelle
  • la possibilité d’organiser et de réutiliser le code
  • la capacité de développer plus rapidement des projets évolutifs et résilients
  • un écosystème mature d’outils de support et de ressources tierces

Le résultat est qu’au moment de la rédaction de cet article, PHP est en tête du classement des langages côté serveur avec un taux indiscutable de 79.1%, devançant le concurrent le plus proche, ASP.NET, avec une marge de 69,9%.

PHP alimente certaines des entités Web les plus influentes de la planète, notamment Facebook (via HVVM), WordPress (qui représente actuellement 39,6% de tous les sites Web ), Wikipedia, Flickr et Tumblr. Il dessert également le demi-milliard d’utilisateurs de la plate-forme de médias sociaux vk.com, ainsi que le département d’État américain, qui a récemment abandonné ASP.NET pour PHP.

Parmi les frameworks côté serveur dérivés de PHP, Laravel et Symfony ont développé une avance constante au cours des dernières années. Puisque Laravel est construit sur la deuxième itération de Symfony (Symfony 2, sorti en 2011), il n’est pas surprenant que leur mission se recoupe beaucoup.

Laravel vs Symfony: origines et intention

Symfony

logo symfony
Laravel vs Symfony
Laravel vs Symfony

Inspiré du Spring Framework de Java, Symfony a été créé par un ingénieur logiciel pour la société française SensioLabs en 2004, et initialement publié sous une licence MIT l’année suivante. La première version stable est apparue en 2007 et Symfony2, une réécriture totale de la base de code en 2011, a prouvé l’étincelle initiale de Laravel (voir ci-dessous).

Symfony est hautement modulaire et est fréquemment utilisé comme une ressource de bibliothèque de composants plutôt que comme une structure intégrale. Il est décrit par le créateur Fabien Potencier comme un «ensemble réutilisable de composants PHP autonomes, découplés et cohésifs qui résolvent les problèmes de développement Web courants». Cependant, il a également décrit Symfony comme «un framework Web complet».

Les sites et projets développés à partir de Symfony (en plus des concurrents directs tels que Laravel, Yii et CakePHP) incluent Drupal, Spotify, DailyMotion et le référentiel de logiciels spatiaux européens de l’ESA. Les projets qui utilisent des composants de Symfony incluent phpBB, Wikimedia, PHPMyAdmin, et l’installation principale de Laravel / Symfony et le packager de gestion Composer.

Au moment de la rédaction de cet article, Symfony est actuellement estimé comme une technologie de support ou de base derrière 53 011 sites Web en direct , et sa version actuelle est 5.2.1

Laravel

logo laravel
Laravel vs Symfony

Laravel a été comparé à une version orientée PHP des concepts de base de Ruby on Rails. Les tentatives précédentes basées sur PHP pour émuler l’élégance et la facilité de RoR incluaient CakePHP et CodeIgniter. En fait, Laravel a été créé par le développeur de l’Arkansas Taylor Otwell en réponse directe aux limitations qu’il percevait dans CodeIgniter, telles que le manque de prise en charge de l’intégration continue (CI – voir ci-dessous).

Laravel est plus engagé dans un paradigme productif de Model-View Controller (MVC) que Symfony. Bien que les deux frameworks soient fréquemment cités comme exemples du modèle architectural MVC, le créateur de Symfony écarte la comparaison :

Je n’aime pas MVC car ce n’est pas ainsi que fonctionne le Web. Symfony2 est un framework HTTP; c’est un cadre de demande / réponse. C’est le gros problème. Les principes fondamentaux de Symfony2 sont centrés sur la spécification HTTP.

Fabien Potencier, Symfony SAS
Laravel vs Symfony
Laravel vs Symfony

Bien que ce serait trop reducteur de décrire Laravel comme «compilé», il est certainement  optimisé  pour le prototypage et le déploiement de développement rapide. Il s’agit d’un détournement conceptuel de bas niveau dans l’intention, et sans doute la plus grande différence entre les deux systèmes : Laravel a été créé comme un bourreau de travail pour les applications Web côté serveur, et non comme  un  tableau à la carte de ressources de bibliothèque discrètes (ce que Symfony peut être utilisé comme).

En ce sens, Laravel existe en aval de la prestigieuse liste de projets dont Symfony peut se vanter, dont beaucoup sélectionnent les technologies de base de Symfony plutôt que de les utiliser comme framework. De plus, Laravel est en soi une descendance de Symfony. Par conséquent, une comparaison à l’identique de l’absorption entre les deux cadres n’est ni possible, ni raisonnable.

Les sites et applications développés avec Laravel incluent InvoiceNinja, TrafficJunky, Zoom, Aimeos, Handesk, Lead Management App, Pricefy et Statamic CMS, parmi beaucoup d’autres. Au moment de la rédaction de cet article, on estime actuellement que Laravel est une technologie de support ou de base derrière  640 792 sites Web en direct , et sa version actuelle est de 8.x

Laravel vs Symfony : Laravel est-il plus rapide que Symfony au Runtime?

Il est très difficile de confirmer l’idée populaire selon laquelle Laravel dépasse Symfony en termes de performances d’exécution. Les sources disponibles ne sont pas impartiales, et des changements de version massifs dans les deux frameworks au cours des 3-4 dernières années ont rendu nombre de ces comptes obsolètes. En outre, il n’existe pas de service d’analyse comparative objectif, puissant ou doté de ressources suffisantes pour fournir des résultats significatifs dans une gamme de scénarios potentiels.

Aucun processus d’analyse comparative ne pourrait non plus prendre en compte les différences inévitables entre la configuration matérielle et réseau, les problèmes de latence créés par des dépendances de tiers sur des technologies ou des flux de données non liés (c’est-à-dire des flux de données basés sur le cloud), des différences de volume, de fréquence (pics de trafic, etc.), la latence basée sur la géolocalisation (distance aux centres de données clés) et l’efficacité de la conception (des bases de données et / ou de la mise en œuvre principale).

Même si vous pensez que les statistiques fréquemment citées sur les performances de Laravel au cours des cinq dernières années environ, les marges généralement citées (50 vs 250 millisecondes, Laravel sur Symfony) peuvent bien être insignifiantes pour votre modèle et vos exigences proposés. Les considérations relatives à la «vitesse» pourraient être considérées de manière plus appropriée dans le contexte du temps et des coûts de développement (voir ci-dessous).

Laravel vs Symfony : Cartographie relationnelle d’objets (ORM)

Le mappage objet-relationnel (ORM) fournit des méthodes de haut niveau pour accéder à une variété de types de bases de données. Il résume les requêtes, opérations et fonctions basées sur SQL dans le modèle de programmation orientée objet (POO). Cela permet le développement plus rapide d’un code plus propre, plus transparent et plus responsable lié aux requêtes de données.

Laravel: ORM éloquent

Laravel utilise Eloquent ORM, qui prend en charge quatre types de base de données prêts à l’emploi: MySQL, PostgreSQL, SQLite et SQL Server (ainsi que SQL brut). Eloquent utilise le modèle Active Record, permettant aux développeurs de rassembler facilement des transactions de création, de lecture, de mise à jour, de suppression (CRUD) et de faire des requêtes économiques de «vérification sale» qui ne rapportent que les éléments modifiés dans la base de données.

Eloquent n’a pas la capacité de Doctrine d’éviter les scénarios de migration en utilisant des schémas de «pont» (voir ci-dessous). Cependant, il peut faciliter les migrations sans qu’il soit nécessaire de définir des champs dans le modèle – un outil que Doctrine n’a pas.

Bien qu’Eloquent soit perçu comme l’une des principales forces de Laravel, il a également été critiqué pour ne pas rester performant à grande échelle et pour ne pas séparer la logique métier de l’architecture de base de données.

En ce qui concerne les performances, cependant, beaucoup admettent que le compromis d’Eloquent entre facilité et vitesse (et le fait qu’il est inévitablement plus lent à l’exécution que le SQL brut) est un échange équitable. Les développeurs utilisent souvent du SQL brut ou Query Builder pour soulager les goulots d’étranglement d’Eloquent dans certaines parties de la base de code.

Symfony: Doctrine ORM

Symfony utilise le tiers Doctrine ORM, qui est également utilisé par d’autres frameworks notables tels que Yii, Zend et CodeIgniter. Doctrine est découplée des composants de Symfony et peut accueillir un large éventail de types de bases de données potentiels, bien que les composants ne fournissent pas explicitement de support natif pour un schéma particulier.

Doctrine peut éviter le besoin de migrations de bases de données en créant un schéma adaptatif une fois que vous avez défini un modèle de parité approprié.

Le modèle de mappeur de Doctrine crée une division très claire entre le schéma de base de données et le fonctionnement logique de l’application. En revanche, Eloquent peut souvent créer des liens inconfortablement étroits entre le schéma et l’application.

Cependant, Doctrine nécessite la création d’une fonction de référentiel pour chaque appel qu’elle fait. Celles-ci peuvent rapidement s’intégrer dans des applications plus complexes, ce qui rend la gouvernance de code potentiellement plus lourde qu’avec Eloquent.

Bien que les développeurs soient plus susceptibles d’avoir de l’expérience avec les packages par défaut de l’un ou l’autre framework, Eloquent et Doctrine peuvent être utilisés dans Laravel ou Symfony selon les besoins.

Générateur de requêtes

Lorsque l’on considère Laravel vs Symfony, il convient de considérer que ce dernier dispose d’un puissant outil supplémentaire pour les demandes. Query Builder n’a pas l’intégrité du modèle d’Eloquent, ainsi que nombre de ses fonctionnalités les plus utiles, telles que la gestion des relations, les mutateurs, les accesseurs et l’horodatage automatisé, entre autres. Cependant, il présente un avantage de vitesse distinctif pour effectuer des demandes et des transactions CRUD.

Modèles de moteurs : Twig vs Blade

Comme avec Eloquent et Doctrine, il est possible de mélanger et de faire correspondre Twig et Blade, les deux moteurs de template standard de Laravel et Symfony, via ce projet GitHub et le référentiel TwigBridge .

Les deux moteurs de modèles implémentent des blocs / sections et l’héritage de modèle. Avec Twig, cependant, les fonctions doivent être définies deux fois, à la fois pour le modèle et pour le contrôleur. Cela peut entraîner un niveau de spécificité fastidieux et une certaine difficulté dans la réutilisation du code par rapport à Blade.

Contrairement à Symfony, Laravel s’est engagé à exploiter toute la diversité des fonctionnalités PHP plutôt que de s’en tenir aux fonctions de plus haut niveau qui permettent d’exploiter Symfony en tant que ressource de bibliothèque. Encore une fois, il s’agit d’une décision de conception et non strictement d’un «avantage»: l’utilisation par Laravel de la fonctionnalité plus idiosyncratique de PHP fait également l’objet de critiques occasionnelles. 

Cependant, cela signifie que Blade peut utiliser des fonctions PHP directement dans sa logique de création de modèles, de sorte que le code soit reflété dans le code du contrôleur. Les services peuvent également être instanciés directement dans un modèle avec la commande @inject, un gain de temps réel.

Néanmoins, l’installation de Blade se fait au prix de brouiller un peu le modèle MVC, car l’introduction de la logique des données dans la couche de présentation affecte dans une certaine mesure la portabilité et la transparence. Puisque Twig utilise un modèle plus portable, il a une vie active en dehors de Symfony, ce qui augmente la base de développeurs qui s’y familiarise.

Blade propose également Lumen, un sous-framework utile pour les microservices et les API. Les fonctionnalités de Lumen peuvent être répliquées dans Symfony, mais pas de manière aussi élégante.

Laravel vs Symfony
Laravel vs Symfony

Intégration continue dans Laravel et Symfony

L’intégration continue (CI) automatise les processus de re-test et de validation qui deviennent nécessaires lorsque la base de code est modifiée. Laravel et Symfony prennent en charge nativement les mêmes six modèles CI :

  • Jenkins, via GitHub (avec des modèles dédiés disponibles pour Laravel et différentes versions de Symfony)
  • Travis et Drone, à la fois des CI basés sur Git et indépendants du framework
  • Style, qui a des modèles pour Laravel et Symfony
  • Circle, qui fournit également des modèles Laravel dédiés
  • CodeShip, accessible via Git, avec des paramètres valides

Laravel vs Symfony : validation de formulaire

Laravel et Symfony abordent la validation des formulaires de manière assez différente. La validation de Laravel se produit contre une entrée, soit à partir d’un formulaire, soit à partir d’une validation de demande manuelle. Le composant Symfony Validator, qui fournit une gamme plus large de services de validation générale, effectue l’opération via l’instanciation d’une classe de Validation , validant efficacement un modèle sur la POO base.

Laravel propose également un hook After Validation flexible, offrant un avantage supplémentaire dans la gestion des erreurs. Dans Symfony, cela nécessiterait une nouvelle instance du validateur (et des fichiers supplémentaires à créer) afin d’atteindre le même objectif. Cependant, les partisans de Symfony ont soutenu que la validation des entrées brutes de l’utilisateur devrait, dans tous les cas, relever des propres routines de validation du formulaire, et que l’approche de plus haut niveau adoptée par Symfony est supérieure en ce qui concerne les traductions.

Ici, pas pour la première fois, la différence entre Laravel et Symfony semble se résumer à la tension entre la facilité d’utilisation (Laravel) et le maintien de l’intégrité d’un modèle découplé de plus haut niveau (Symfony) des thèmes qui sous-entendent les principes fondamentaux et les intentions des deux frameworks, respectivement.

Laravel vs Symfony : courbe d’apprentissage, documentation en ligne et support

En raison de sa détermination à fournir des composants portables, découplés et flexibles, Symfony est généralement perçu comme ayant une courbe d’apprentissage plus élevée que Laravel. Cette considération est exacerbée par la quantité supérieure de matériel d’apprentissage en ligne et de ressources disponibles pour Laravel.

Pour 99 $ par an, les utilisateurs peuvent s’abonner à tout le contenu de Laracasts, une énorme ressource communautaire qui fournit des forums ouverts et des didacticiels vidéo. La plupart du contenu est disponible sans abonnement. Le domaine compte actuellement plus de 65 000 threads, tandis que les forums laravel.io complémentaires (et gratuits) proposent plus de 15 000 sujets.

Symfony a un Slack Chat actif et une gamme très respectée et bien ordonnée de documentation en ligne. Cependant, il a détourné les efforts antérieurs de développement du forum vers Stack Overflow.

Au moment de la rédaction de cet article, Stack Overflow approche les 164 698 questions questions liées à Laravel, moins d’un tiers des questions liées à Symfony (67 760) dans ce domaine. Que ce soit parce que les ressources dédiées de Laravel sont plus convaincantes, ou que Symfony est plus technique (ou demande plus de connaissances !) La question est ouverte à l’interprétation.

SensioLabs, le créateur de Symfony, propose un support payant pour la suite, alors que le conseil professionnel autour de Laravel n’est disponible que via des sociétés indépendantes.

Laravel vs Symfony : Conclusion

Laravel reste un projet enfant de Symfony. Il a intentionnellement abandonné certaines des fonctionnalités de développement les plus attrayantes de son ancêtre en échange de la possibilité de fournir un prototypage et un déploiement rapides. Cependant, certains des raccourcis qui facilitent ses flux de travail de développement rationalisés (comme la diminution de la distinction entre les données et la conception dans certains aspects du cadre) pourraient poser des problèmes à un projet s’il devait un jour évoluer plus haut que prévu initialement.

L intégrité de la conception de Symfony lui donne le potentiel de récompenser un investissement initial plus important en temps et en argent avec une implémentation de projet plus stable et capable d’évoluer. Si vous êtes impressionné par la prestigieuse écurie d’utilisateurs de Symfony, il convient de rappeler que peu des plus grands noms de cette liste utilisent Symfony comme framework de base. Étant donné que sa mission est divisée entre la fourniture de modules et un cadre cohérent, Symfony pourrait être considéré comme ayant moins d’intégrité conceptuelle que Laravel.

L’avantage de longue date de la vitesse d’exécution (peut-être apocryphe) de Laravel semble s’éroder car le framework Symfony résout ce problème à chaque version. Par conséquent, le principal facteur de recommandation de Laravel par rapport à Symfony découle de sa courbe d’apprentissage plus facile, ainsi que de sa documentation en ligne et de sa communauté de développeurs extraordinairement complètes.

Voici notre conclusion concernant le match : laravel vs symfony

Nos développeurs PHP sont prêts à vous accompagner à la tâche lorsque vous avez besoin d’une assistance professionnelle PHP. Pour discuter de votre projet et vous conseiller pour le choix de la pile technologique adapté à votre projet.

Pour tout renseignement sur nos services d’agence digitale à Montpellier. Contactez-nous via le chat de notre site web du lundi au vendredi de 9h00 à 18h00

Demander un devis Solutions Développement I Solutions Design Graphique I Solutions Marketing Digital I Blog