Pourquoi utilisez-vous Symfony ?

gordon · Décembre 24, 2014, 8:46

Bonjour.

Tout d’abord un nécessaire avertissement : je développe essentiellement en python et Django, avec un très gros passif sur PHP. J’éprouve une haine farouche envers Symfony2, et j’espère que ce thread m’aidera à faire la part des choses là-dessus pour retirer l’émotionnel. Naturellement, il a donc un potentiel trollesque presque radioactif, mais si je parviens à rester courtois et constructif, vous devriez pouvoir l’être aussi.

J’ai essayé de tirer profit de Symfony2. Vraiment. Je forme parfois dessus. Et ça me fait mal, tant je vois de points faibles à ce framework, sans réel bénéfice pour contre-balancer.

Et s’il y a bien une chose que je ne m’explique pas, c’est le succès fou de Symfony dans le milieu pro. Est-il à ce point meilleur que tous ses concurrents ? En quoi ? La barrière de l’apprentissage et le coût de son utilisation sont-ils négligeables par rapport aux fonctionnalités ? Est-ce plus efficace que d’opter pour un autre framework, éventuellement dans un autre langage, à la courbe de progression plus souple ?

Pour détailler ce que je reproche à Symfony :

une installation inconsistante : selon les versions, on propose Composer, ou une ligne curl pour télécharger un installeur Symfony (sans HTTPS !)
un directory ultra-complexe : ça fout une grosse claque sur la découverte du framework, et même ensuite, c’est bien trop compliqué. Un projet Django classique a un, voire deux, à tout casser, niveaux d’arborescence, pourquoi autant de complications ?
une doc oscillant de « pas géniale » à « franchement mauvaise »
un nommage incompréhensible, qui redéfinit à la volée du vocabulaire (sérieusement, « la sécurité » ça signifie « les ACL et l’authentification » pour Symfony !)
l’utilisation de syntaxes non-natives : YAML, Twig (qui est une syntaxe Python), les annotations, DQL… pour moi, un dev utilisant Symfony le fait typiquement quand il ne connaît pas d’autre langage : pourquoi lui en mettre tout de même dans les pattes ?
une API orientée vers la complexité maximale, alors qu’elle devrait faciliter les tâches usuelles
les performances…

Saurez-vous me convaincre de l’intérêt de Symfony ?

Toilal · Décembre 24, 2014, 11:14

Pour enflammer un peu la discussion dés le début, je pense que tous les développeurs PHP devraient passer à autre chose (que PHP). J’ai fait beaucoup de PHP quand j’étais plus jeune, et les alternatives à l’époque etaient CGI, et … CGI (du C en somme). Autant dire que le choix était vite fait.

Si Symfony est un framework populaire, c’est parce que beaucoup de personnes pensent encore qu’aujourd’hui PHP est le meilleur moyen de faire du web, et que le surcoût d’apprentissage d’un nouveau langage leur parait trop important.

Quand on voit les possibilités offertes ajourd’hui par d’autres langages, je pense à Python, mais aussi aux langages de JVM (Java, Scala … sans compter toutes les librairies d’excellentes qualité à disposition sur la JVM), il suffit de s’y intéresser pour faire la transition.

rkueny · Décembre 25, 2014, 4:11

Ah oui gros sujet qui va attirer du troll :)

Pour ma part j’utilise principalement PHP et Symfony2 professionnellement et personnellement. Je vais essayer de répondre aux défauts que tu pointes.

une installation inconsistante : selon les versions, on propose Composer, ou une ligne curl pour télécharger un installeur Symfony (sans HTTPS !)

On te propose plusieurs façons d’installer Sf c’est tout. Je ne vois pas ce qui est génant. Pareil, pour un installeur Sf je ne vois pas pourquoi tu aurais besoin d’un https, il y a quoi de sensible ?

un directory ultra-complexe : ça fout une grosse claque sur la découverte du framework, et même ensuite, c’est bien trop compliqué. Un projet Django classique a un, voire deux, à tout casser, niveaux d’arborescence, pourquoi autant de complications ?

Tu peux faire un peu comme tu veux au niveau de l’architecture de tes dossiers. Tu t’organises comme tu veux.

une doc oscillant de « pas géniale » à « franchement mauvaise »

Sérieusement ? Je trouve que la doc est vraiment bonne et surtout tu as une très grosse communauté du coup tu trouves toujours une réponse à ta question.

l’utilisation de syntaxes non-natives : YAML, Twig (qui est une syntaxe Python), les annotations, DQL… pour moi, un dev utilisant Symfony le fait typiquement quand il ne connaît pas d’autre langage : pourquoi lui en mettre tout de même dans les pattes ?

Tu charges ce que tu veux. Tu n’es pas obligé d’utiliser YAML, tu peux configurer en PHP ou XML par exemple. Tu peux utiliser le système de template que tu veux etc … Après Twig est reconnu comme étant tout de même l’un des meilleurs. Pour les annotations, y a des pour et des contres mais perso je les utilise beaucoup.

les performances…

On le cite souvent en défaut et pourtant je trouve qu’il s’en sort très bien dès que tu sais l’utiliser. Parfois il faut se passer de Doctrine2 mais je trouve que le framework s’en sort très bien quand même. Même si sur les grosses applis tu lui colle souvent un gros varnish ou quelque chose du genre.

Pour répondre à @Toilal, je dirais chacun ses choix :) Je trouve que malgré tout ses défauts PHP me convient très bien, convient très bien à ce que je veux faire et je n’ai aucune envie de faire du Python, du ruby ou autre !

gordon · Décembre 25, 2014, 5:28

@rkueny, as-tu une expérience d’autres frameworks web ?

rkueny · Décembre 26, 2014, 11:30

Oui. J’ai fait du Yii, Laravel, Symfony 1.* et du Zend. J’ai aussi joué avec Django mais Sf2 reste mon favori.

gordon · Décembre 26, 2014, 12:57

Alors, pour être honnête, je n’arrive pas à comprendre ta réponse. Tu ne réponds pas à « pourquoi utilisez-vous Symfony », mais « comment faites-vous pour l’utiliser malgré tout », avec des points qui me semblent problématiques.

Sur le fond d’abord : un framework est, littéralement, un cadre de travail. Si pour en tirer profit, il faut sortir du cadre, ne pas respecter ses conventions, et surtout ne pas utiliser certains composants au cœur du framework, quelle est l’utilité d’utiliser ce framework ?

Maintenant, en essayant d’éviter la quotewar, quelques points qui me semblent critiques :

Comment savoir sur le long terme quelle est la méthode la mieux reconnue ? La dernière fois que j’ai testé, les deux méthodes installaient des choses différentes, à tel point qu’on ne pouvait pas suivre le quickstart car les bundles activés n’étaient pas les mêmes.

Concernant le TLS… Quand tu développes une application basée sur Symfony, il est indispensable que le code du framework soit sûr. Les conséquences d’un code malicieux intégré dans le framework seraient désastreuses, et ton application peut être infectée avant même d’être écrite. Si l’installeur se récupère sans HTTPS, la modification à la volée du code récupéré est triviale. Pour faire les choses bien, il faut non seulement une connexion chiffrée et vérifiée pour le transport, mais aussi une signature asymétrique de l’archive, par les devs. N’en déplaise à Sensio, c’est ça qu’on appelle la sécurité, pas les ACL.

Je ne remet pas en question la communauté, qui est certes très active. Mais répondre « tu trouves tes réponses dans les sites communautaires » à une critique de la documentation ne fait que confirmer mon opinion.

Un choix par défaut est très lourd en conséquences. Le fait n’est pas d’avoir le choix, mais que par défaut, Symfony propose (pour ne pas dire « recommande ») ces choix-là. Quand on cherche à apprendre, on commence par faire comme dit la doc, qui en l’occurrence fait des choix contestables.

Je recommande un très bon article (en anglais) sur l’importance de ces choix par défaut

Non (va directement à la slide 35).

Pierstoval · Avril 28, 2016, 1:22

Concernant tes slides, je voudrais bien voir quelles applications ont été testées et quel en est le contenu.

Le dernier post datant de 2014, je déterre ce topic.

Depuis le temps, pas mal de chose ont changé. À l’époque l’installeur de Symfony était extrêmement limité, tout jeune. Certes il n’utilise toujours pas HTTPS pour télécharger le package (pas comme composer par exemple) mais je ne vois pas où est le problème en soi…

une installation inconsistante : selon les versions, on propose Composer, ou une ligne curl pour télécharger un installeur Symfony (sans HTTPS !)

Maintenant l’installeur est la méthode recommandée et proposée par défaut sur le site officielle. Composer est toujours dispo mais n’a pas le même comportement.

un directory ultra-complexe : ça fout une grosse claque sur la découverte du framework, et même ensuite, c’est bien trop compliqué. Un projet Django classique a un, voire deux, à tout casser, niveaux d’arborescence, pourquoi autant de complications ?

app, src, web, tu trouves que c’est beaucoup ? Sérieux ? Le dossier bin est accessoire et est là juste pour accueilir les exécutables (pour éviter de tout cumuler à la racine, là où y’a tes fichiers pour composer, phpunit, npm, travis-ci, coveralls, README, et tous les CI que tu veux)., et le dossier vendor on s’en tape puisqu’il n’est pas versionné et correspond aux composants installé via Composer.

Du coup les seuls dossiers que tu utiliseras sont vraiment app, src et web.

une doc oscillant de « pas géniale » à « franchement mauvaise »

C’est pas un argument, c’est un jugement, donc il est impossible de commenter ça. Quand t’as un bug sur Symfony, tu vas sur google, tu tapes ce dont t’as besoin, et 80% du temps tu tombes sur symfony.com, 15% sur stackoverflow, et 5% sur des blogs/sites de développeurs.

un nommage incompréhensible, qui redéfinit à la volée du vocabulaire (sérieusement, « la sécurité » ça signifie « les ACL et l’authentification » pour Symfony !)

Tout ça vient du composant “Security”. Tu l’aurais appelé comment ? “Authentication” ? Si tu avais vraiment lu la doc tu comprendrais que “Security” comprend effectivement “authentification” et “permission”. (et pas juste “acl” qui fait partie des permissions)

l’utilisation de syntaxes non-natives : YAML, Twig (qui est une syntaxe Python), les annotations, DQL… pour moi, un dev utilisant Symfony le fait typiquement quand il ne connaît pas d’autre langage : pourquoi lui en mettre tout de même dans les pattes ?

Comme dit plus haut, pour la config, tu peux utiliser YML, XML, PHP ou les annotations, y’a aucune “bonne” solution par rapport à d’autres. Twig est un moteur de template basé sur Jinja, c’est clair, mais où est le problème si Jinja est cool et qu’il a sa “version PHP” ?

Pour ce qui est de DQL c’est le principe d’un ORM : tu fais du DQL comme ça tu peux passer de MySQL à Sqlite ou PostgreSQL sans jamais toucher à ton code, tu changes juste la config : passer de pdo_mysql à pdo_sqlite c’est pas vraiment problématique, je pense.
Qui plus est, DQL reste dans l’idée d’un ORM et il est entity-centric, tu fais des requêtes “orientées objet”, vu que tu sélectionnes les propriétés de l’objet et pas les champs de la BDD.
Et sinon tu utilises le QueryBuilder et comme ça tu peux faire du vrai orienté objet en mode fluent.

une API orientée vers la complexité maximale, alors qu’elle devrait faciliter les tâches usuelles

L’API est complexe mais elle est hyper bien documentée, et très souvent tu n’as même pas besoin de lire la doc officielle, la doc des interfaces est souvent suffisante pour comprendre le fonctionnement des différentes classes.

les performances…

Symfony intègre un cache http pour la prod, ce qui est énorme déjà, et il intègre pas mal de composants facilitant l’ajout d’un proxy varnish (gestion d’ESI, annotations/méthodes pour le cache http, etc.).
Si les perfs sont nulles c’est souvent le développeur derrière qui a mal fait son travail.

J’en discutais pas plus tard que ce matin avec des collègues qui trouvaient que Doctrine était trop lourd (ouais, les metadata en mémoire avec APCu ou Memcache, c’est vrai que c’est lourd… -_- ), j’analyse du code, je vois 130 requêtes sql exécutées, j’optimise ça et j’obtiens 5 requêtes SQL, j’ai augmenté les perfs de 250% (plus de 400% de perfs en plus avec Redis, mais ils ont pas voulu que je l’intègre) environ après un bench.

Symfony lui-même, comme tout framework, est une base de travail.

Après, c’est aux développeurs de travailler correctement et d’optimiser le code.

Et si ça suffit pas, c’est aux devops/sysadmins de modifier la stack pour avoir un listing de blog qui se charge en 20ms…

Symfony c’est un moyen, rien d’autre.

Et s’il est si populaire c’est aussi parce que la politique derrière est très stricte.

Pense à Laravel : en 5.0 y’a une feature qui est imaginée, elle est ajoutée en 5.1, supprimée en 5.2, tu trouves ça propre ? Perso, j’aime pas, et rien que ça, ça me refroidit.
Symfony ajoute les features sur la version mineure ultérieure, et a une politique de respect total des BC (rétro-compatibilités), ce qui fait que si t’as une appli sous Symfony 2.5 et que t’installes Symfony 2.8, ton appli fonctionne toujours. Et ça sera encore plus flagrant depuis que SF3 est arrivé, parce que Symfony 2.8 a ajouté un gestionnaire de déprécations : tout ce qui est “déprécié et sera supprimé à la version X.0” est ajouté dans des logs en mode dev (et via le phpunit bridge, du coup tes tests unitaires / fonctionnels affichent aussi les déprécations) ce qui te permet déjà de préparer la migration de ton appli vers une version majeure supérieure.

Pour info, une version mineure (2.5, 2.6, 2.7) ajoute des features et des déprécations.
Une version majeure (3.0, 4.0) supprime toutes les déprécations annoncées à la version majeure précédente (sachant que toute déprécation est systématiquement annoncée). Et désormais les versions majeures n’ajoutent aucune feature, seules les versions mineures en ajoutent.
Et les versions patch (2.8.1, 2.8.2, 2.8.3) n’ont que des correctifs de bugs, ce qui te permet d’être sûr à 200% qu’elles sont rétro-compatibles.
Y’a pas de politique comme ça dans les autres frameworks PHP.

D’autres arguments à donner, à part le fait que “t’aimes pas” ?

Et puis accessoirement, Fabien Potencier, créateur de Symfony, a lui-même annoncé au hack.summit (y’a 1 ou 2 ans, je sais plus) que PHP est un mauvais langage, et c’est pour ça qu’il a toujours voulu que Symfony soit porteur de paroles de “bonnes pratiques” pour éviter aux devs PHP de faire de la merde.
Et c’est aussi pour ça qu’a été créé PHP-Fig, entre autres.