Dans la mesure où au boulot les applications symfony commencent à se multiplier (on va passer de 1 à 2, restons modestes ;-) ) et que je songeais par ailleurs à recoder une appli existante en symfony pour des raisons de compétences internes à JCDecaux (Python/Django, c'est pas gagné a priori...), je me suis décidé à me (re)plonger dans Symfony.

Après quelques heures de lectures et fait le tutoriel en une heure et surtout le tutoriel Jobeet, voici ce que j'en retire par rapport à mon expérience sur Django. (pour être tout à fait honnête, j'ai consciencieusement suivi le tutoriel jusqu'à la fin du jour 7 - après, j'ai lu avec attention mais pas recopié les bouts de code).

Cela n'engage bien sur que moi, je suis ouvert à toute discussion constructive et cela ne se veut pas être un nid à troll ;-) N'ayant pas non plus lu toute la documentation Symfony, je peux dire des âneries ou des choses fausses car non présentées dans les documents que j'ai pu lire.

Sur les modèles :

  • Relations OneToOne, OneToMany ou ManyToMany : avantage Django puisque beaucoup plus limpide et pas besoin de déclarer les tables intermédiaires pour les relations ManyToMany. A contrario, cela peut paraître trop magique
  • Type de modèle : avantage Django. Symfony reste sur les types "de base" et il faut donc appeler ensuite un validateur pour valider le contenu d'un champ. Avec Django, c'est du tout en un par ex : models.UrlField qui ne stocke qu'une url et vérifie si elle est valide (et éventuellement si elle existe bien)

Routing :

  • Avantage Symfony sur les "Route Collection Class" : en gros en déclarant une fois par ex SfDoctrineCollectionRoute, cela vous met automatiquement les 7 méthodes à disposition (de base, new, create, edit, update, delete, show). Dans django, à ma connaissance, cela n'existe pas.
  • Avantage Django sur la flexibilité des urls (mais en est-ce vraiment un). On peut sortir du /module/action/param de Symfony. Ex-aequo sur la capacité à créer son schema d'url (merci Niko pour la correction)
  • Définition des routes : Avantage Symfony - les possibilités ont l'air plus fines (limité une route à une méthode par ex) et plus lisibles à mettre en oeuvre (les regexps des routes Django sont pas les plus simples à mon sens). Par contre, c'est sur que les routes Django sont du coup moins verbeuses que celle de Symfony (là encore, ça se discute)
  • Les urls par défaut fonctionnent de base sous Symfony. Le /module/action a pour avantage de pouvoir jouer tout de suite avec Symfony. Sous Django, cela n'est pas possible de sauter la case urls.py.

Fixtures :

  • Sous Symfony, il est intéressant de voir que l'on peut faire une boucle "for" pour insérer des fixtures en masse

Formulaires :

  • Symfony s'inspirant officiellement de django.forms, je ne reviendrais pas là dessus.

Templating :

  • Même si PHP peut être vu comme un langage de template en tant que tel, je suis plutôt adepte de l'approche de django.
  • Avantage Symfony sur les "partials". Je ne vois pas trop l'équivalent sous django de prime abord. C'est autre chose que l'héritage de template...
  • Avantage Symfony sur la gestion des "flash" (inspiré de Rails de mémoire). N'existe pas à ma connaissance sous Django.

Tests :

  • Pas de comparatif, je n'ai pas pris le temps de regarder ceux de django (aie, pas taper...)
  • En me basant sur la lecture j'ai l'impression que les tests de Symfony vont plus loin (tests unitaites + fonctionnels)

Authentification/Authorisation/Cache :

  • Ex-aequo ?

Gestion des "settings" :

  • Avantage Symfony (sous réserve d'aimer YAML) vu qu'il est possible de renseigner un fichier <module>/config/app.yml par ex. Ca évite de polluer le settings.py ou d'oublier des settings sur votre machine de dev lors d'un déploiement en prod.
  • Avantage Symfony sur la gestion des environnements sur le principe. Après tout dépend comment se fait le déploiement et qui le gère... (par ex, je ne donne pas les identifiants de prod aux équipes de dev au bureau...)

Interface d'admin :

  • Avantage Django je trouve, même si le fait qu'il faille maintenant toucher à admin.py rend l'accès à l'interface un peu plus fastidieux.
  • Le chevauchement de l'admin Symfony entre les données et le formulaire de tri sous Safari sur mon macbook n'aide pas non plus...

PHP / Python :

  • Même si j'arrive à lire la syntaxe PHP (que de progrès...), je trouve celle de python beaucoup plus agréable à lire et les $this-> et les foo::bar me laissent toujours perplexe ;-)
  • J'ai l'impression (donc totalement subjectif) que pour un résultat égal, il y aurait bcp plus de lignes dans un projet Symfony que Django

Plugins vs Applications redistribuables :

  • Dans django, tout est application et il est assez aisé de les redistribuer. Sous Symfony, cela prend le nom de plugins et je pense au final que c'est assez équivalent.
  • Symfony a un gros avantage, c'est que les plugins sont officiellement référencés. Pour django, faut passer par la case Google ou chercher dans les entrailes de github, bitbucket, google-code.

Globalement :

  • J'ai l'impression que Python/Django est de plus haut niveau (dans le sens macro/micro et non qualitatif) que PHP/Symfony. Je rajoute volontairement le langage car je me demande si ça ne vient pas également du langage et non uniquement du mode d'implémentation du framework. A l'inverse, on a peut être un niveau de granularité plus fin avec Symfony ?
  • J'ai une impression de "trop de fichiers" dans Symfony et de me noyer un peu dans cet ensemble.
  • Le tutoriel en une heure qui n'existe pas en version doctrine, c'est un peu dommage lorsqu'on veut partir sur Doctrine dès le départ
  • La double doc en version doctrine / propel est peut être source de confusion
  • Django et Symfony ont tous les deux une doc de qualité, même si parfois je m'y perds un peu (l'une comme l'autre).
  • Symfony est dans une logique beaucoup plus stricte au niveau MVC quand Django fait du MVT (Modèle Vue Template)

Pour bien faire, il faudrait faire un jobeet en version Django pour se faire une véritable idée sur les 2 frameworks. Pas sur d'avoir envie de faire ça dans l'immédiat par contre...

Personnellement :

  • J'y vois plus clair sur Symfony et c'était le but de l'exercice
  • je pense aller titiller un peu l'équipe de dev sur quelques points en particulier à mon retour de congés ;-)
  • Pour coder à titre perso, je vais rester sur Django

Au plaisir d'échanger avec vous maintenant (pour les qqs uns qui ne seraient pas en vacances) :-)