Retour d’expérience sur FLOW3 et Django

Par défaut

Cet article n’a pas pour objectif de comparer ces deux frameworks et il ne prétent pas être une synthèse complète et objective. J’ai tout simplement passé un peu de temps sur chacun d’eux et ceci est mon ressenti vis à vis de ma montée en compétence.

Intro

Pour moi la découverte de nouvelles technos passe souvent par un nouveau projet. J’ai besoin d’une idée à réaliser pour pouvoir mettre en pratique ce que j’ai envie d’essayer. Etant freelance il n’est pas facile de consacrer du temps à l’autoformation. Peu de client souhaite payer votre montée en compétence et en général on évite de s’aventurer répondant à des marchés portant sur des technos non maitrisées. Bref, à chacun sa stratégie.

Ainsi donc il me faut un projet perso à réaliser. Une fois trouvé, je me retrouve généralement dans les dynamique suivante : 50% de ma motivation pour l’idée en elle même du projet et 50% pour la techno à tester.
Quand je dis techno, c’est au sens large : ça peut être un langage, un framework, un composant technique, un environnement ou même un concept.

Ces derniers temps il me trottait dans la tête une envie de remettre sur pied un vieux projet. Les idées se bouscoulent, tout ça tombe bien, j’ai très envie de tester FLOW3, un nouveau framework PHP développé par la communauté TYPO3.

FLOW3

Venant de faire un peu de Zend Framework (v1) et en étant assez déçu, je me mets donc à la recherche d’infos et de retours sur ce nouveau framework qui semble bien conçu et bourré de concepts sympas. Slideshare est rempli de présentations toutes plus convaincantes les unes que les autres.

FLOW3 est un framework MVC composé d’un tas de truc qui font brillées les yeux des développeurs php (surtout s’il vient du milieu TYPO3) : AOP, Injection de dépendance, Doctrine, annotations, FLUID (moteur de template), cache, sécurité, etc. A cette époque nous en somme à la version 1.0.

Bref je ne vais pas plus développer et simplement dire que j’ai été déçu.
Ce framework est encore jeune et même si ce qui est documenté est bien documenté il y a, d’une façon générale, encore un énorme manque de ressources. Soit, pour résumer :

  • La doc est loin d’être finie et je trouve que souvent, la mise en pratique de ce qu’on vient de lire n’est pas toujours évidente. Tout est tellement découpé et conceptualisé qu’il faut manipuler énormément de chose pour faire parfois un truc simple
  • Le framework est jeune et du coup il y a des changements importants qui sont encore opérés (1.0 => 1.2 : authentification, gestion des packages, models / repository, i18n). 
  • Peu d’exemple et peu de code disponible : le fait d’avoir quelques projets libres utilisant une techno est facteur d’inspiration. On (je ?) débloque souvent une situation en m’inspirant de ce qui a été fait. Exemple d’un manque : l’i18n (mais la doc a été améliorée depuis il me semble).
  • Peu de modules / extensions / plugins : autre type d’authentification, autre type de bdd, éditeur wysiwyg, bootstrap, captcha, compresseur css/js, etc, etc
  • Une petite communauté ce qui veut dire avoir de la patience : les personnes pouvant vous répondre ne sont pas nombreuses
Alors voilà, l’aventure FLOW3 s’arrête là pour le moment. Il y a de forte chance que j’y revienne d’ici quelques temps car ce framework est vraiment prometteur … mais aussi parce que j’avoue aimer tout ce qui se rapproche à la communauté TYPO3 (les développeurs, l’esprit qui se dégage des projets, la façon dont la communauté interagit).
Très modeste contribution : FLOW3.Facebook : un package que j’ai réalisé permettant l’authentification via Facebook.

Django

Deux copains venant eux aussi de PHP me disaient fréquemment de jeter un oeil sur Django, que c’était vraiment top. Mon projet se réalisant avec eux et voyant que je ne suis pas très productif sur FLOW3, je me décide à m’y essayer. Petite info au passage, je n’ai jamais fais de Python.

Django est un framework Python qui met particulièrement l’accent sur 6 points : l’ORM, l’interface admin, la gestion des url, le système de template, la gestion du cache et l’internationalisation. Ca fait un tas d’autre chose mais, globalement, c’est sur ces points que le focus est mis.

Me voilà donc parti. Premier constat, c’est surprenant d’efficacité et de simplicité, en peu de temps j’arrive à recoder ce que j’ai fait sous FLOW3. Bref : « Django is a high-level Python Web framework that encourages rapid development and clean, pragmatic design. »

Vous l’aurez compris, Django m’a plu.

  • La documentation ! Si tous les frameworks pouvaient être aussi bien documenté (tacle ZF), se serait merveilleux. La doc en elle même suffit, elle est plein d’exemples et on se retrouve rarement à devoir chercher des tutos ailleurs
  • L’aide et les exemples : une petite recherche dans google qui vous emmènera probablement vers Stackoverflow et vous trouverez votre réponse dans la minute qui suit. Au départ les questions portent plus sur Python que sur Django :)
  • Les applications (comprendre « plugins ») : il existe déjà des applications pour un nombre incalculable de besoin. Authentification social, gestion de tache cyclique, éditeur wysiwyg, « boostrapiser » vos formulaires, gérer les assets, bref Github et djangopackages.com sont vos amis. Vous avez besoin d’une apps ? « pip install son-nom ».
  • L’ORM : pour le moment, je n’ai pas eu l’occasion d’utiliser quelque chose de mieux tout simplement. Les models se définissent très simplement, il n’y a pas d’accesseurs à entretenir, pas d’annonation (généralement mal géré par les IDE), tout est simple et limpide. Le requêtage est formidable. 
  • Le moteur de template : loin de Fluid ou Smarty qui nécessitent d’apprendre un pseudo langage … ce que je trouve lourdingue. Ici c’est tout simple, il y a 3 ou 4 trucs de base à savoir en gros : afficher une variable, faire une boucle et affiche un block. 
  • L’interface admin : certains frameworks commencent à le faire mais c’est semble t’il Django qui est au top la dessus. Une interface admin est toute prête et vous n’avez soin qu’à spécifier les modèles que vous souhaitez gérer. Il s’occupe du reste (CRUD) avec de l’ajax quand les modèles sont liés, des tris et filtres sur les listes d’enregistrements, organisation pour onglet, etc.
Une seule chose m’a quelque peu troublé au départ. Bien souvent les frameworks imposent une architecture souvent liée au MVC, comme par exemple un découpage par « application » sous ZF, par package sous FLOW3; chacun d’eux embarque un dossier pour les contrôleurs / modèles / vues. 
Django est beaucoup plus souple : il y a également un découpage « application » mais libre à chacun de faire ce qu’il veut de celle-ci, c’est un dossier vide. Pas d’obligation d’avoir une structure MVC dedans. L’application peut, par exemple servir à morceler votre site avec une application pour le frontend et une pour le backend. Ou bien, une application pour toutes les vues et une pour les modèles. 
Rien de dramatique mais c’est un légèrement perturbant lorsqu’on vient de framework très encadrants. Il n’y a pas de bonne façon de faire, à chacun de gérer.  

Un mot sur Python.

Voilà de nombreuses années que je fais du PHP et jusqu’à maintenant lorsque je lisais un article qui portait un regard critique sur PHP, … je dois avouer que j’avais du mal. En gros j’aurais dis : PHP se traine un lourd passé mais il permet de bien faire son boulot comme n’importe quel langage.
Aujourd’hui je dois bien avouer que lorsque je vois Django, il me semble indéniable que la qualité de ce framework est en bonne partie liée à Python. Ce que je veux dire c’est que même si Django a bien été conçu / pensé, reproduire ce framework dans un autre langage n’aura pas du tout eu le même résultat.
J’ai le sentiment que l’on se retrouve à avoir et à faire moins de couche, moins d’abstraction et à utiliser moins de pattern. Bref c’est mon sentiment et je ne me prétends pas expert.
En tout cas il va me falloir avaler encore quelques milliers de ligne de python avant de pouvoir être réellement efficace. Python regorge d’astuces et de fonctionnalités. Il y a des bouts de code de 2 lignes qui calment n’importe quel débutant pendant 1h :)

Conclusion

Django m’a totalement convaincu mais il faut bien avouer que pour l’heure il est encore assez peu utiliser en France. La monté en compétence sur ce framework est rapide et « fun ». J’ai franchement pris du plaisir à le faire … ce qui à moins été le cas avec FLOW3 ou Zend Framework.
Je reviendrai à FLOW3 parce qu’il y a plein de choses intéressantes dedans mais aussi parce que ce framework est de plus en plus lié à TYPO3 (Extbase, TYPO3 v6).

Et maintenant pourquoi pas Play! Framework ?


5 Comments

  1. Bien d’accord pour FLOW3, même si mine de rien, on peut déjà faire de bonnes applis en creusant un peu. Mais comme tu dis, c’est très frustrant d’avoir aussi peu de doc. Par contre, je suis surpris qu’aussi peu de monde n’essaie de l’utiliser? Presque aucun article sur le web, mise à part la communauté allemande…

    • Disons qu’il existe déjà un bon nombre de framework php, se faire un nom n’est pas facile je pense. Le truc c’est qu’avec Django il n’y a pas besoin de bcp creuser, on trouve vite les solutions. C’est là qu’avec le recul tu te dis qu’il y a une année lumière entre les deux framework.

      Super site, super photos en passant :)

  2. Le problème de Django, c’est qu’il était à la mode il y a 2-3 ans sous l’impulsion de Google, mais qu’il commence sérieusement à s’essouffler. Le rythme de mise à jour est très très lent, les patchs proposés mettent des plombes à être testés et intégrés, etc…
    Ruby On Rails est passé par là, Django n’est plus à la mode et c’est bien dommage.

    • Sans connaitre le milieu plus que ça je dirais que Django se trouve dans un moment de transition, le passage à Python 3. Alors c’est sur, lorsqu’un framework passe par ce genre d’étape charnière, ça a légèrement tendance à ralentir. Les gens réservent leurs efforts pour après.

      Ensuite quand je vois passer les actus, les comptes rendus des DjangoCon / PyCon, j’ai pas la sensation que ça chaume ou que la communauté s’essouffle. Sur GitHub, beaucoup de projet Django sont actifs.

      J’ai pas non plus la sensation que RoR prend le dessus. Dans bcp de billet que vois, la conclusion est souvent que les deux solutions se valent.

      Je dirais aussi que Django est relativement mature, il y a maintenant des apps pour tout et c’est peut aussi ce qui explique cette sensation de ralentissement, il y a moins d’effervescence.

      Bref c’est que mon point de vue, je trempe dedans depuis peu de temps alors peu être que je manque un peu de recule. De plus je ne connais pas (encore) RoR.

  3. Article intéressant ; on n’a pas toujours la possibilité de comparer plusieurs technos/framework objectivement au même moment. As-tu déjà eu l’occasion de jeter un oeil à CakePHP ? Je serai curieux de savoir où tu le places par rapport à ces deux expériences. Merci d’avance de ta réponse.

Leave a Reply