article.md 11KB
title: Développement web python et frameworks, tour d'horizon début 2007 slug: developpement-web-python-et-frameworks-tour-d-horizon-debut-2007 date: 2007-03-30 21:23:28 type: post vignette: images/logos/pylons_django.png contextual_title1: Sortie de Django 1.0, une année de nouveautés contextual_url1: 20080902-sortie-de-django-10-une-annee-de-nouveautes contextual_title2: Des vacances et des liens contextual_url2: 20071007-des-vacances-et-des-liens contextual_title3: Une solution pour faciliter la conception d'applications web RESTful avec Django contextual_url3: 20070807-une-solution-pour-faciliter-la-conception-d-applications-web-restful-avec-django
Un article intitulé « Python web development and frameworks in 2007 » très intéressant que j'aurais aimé traduire fait le bilan sur le développement web python et ses principaux frameworks, de web.py à Zope, en passant par Django, Pylons et TurboGears. J'ai appris de nombreuses choses donc je vous invite à aller le lire sur place mais c'est vrai que c'est assez long donc en voici un résumé accompagné de mes commentaires.
Rappel préliminaire : alors que David H. (principal développeur de Ruby on Rails) se moque gentiment du nombre de frameworks python assez paradoxal compte tenu de la maxime de Python : There Is Only One Way To Do It (en opposition à Perl), l'auteur de l'article rappelle que la diversité appelle l'émulation (et le choix pour les utilisateurs) et que la situation actuelle donne raison à Python compte-tenu du manque de réactivité dans le développement de Ruby on Rails. Je ne sais pas où en est le développement actuel de RoR donc je ne peux pas commenter cette affirmation même si je soupçonne un certain parti pris... quelqu'un pour confirmer/infirmer ?
Pour commencer, l'auteur fait le point sur les deux solutions que l'on peut considérer comme étant aux antipodes du développement web python : Zope et web.py. Zope a longtemps été la seule solution pour faire du web sérieusement en Python et souffre (malheureusement ?) de l'image d'usine à gaz qui la poursuit depuis l'arrivée des « nouveaux » frameworks web. Ce n'est pourtant pas une solution à rejeter pour certaines tâches car de nombreux composants sont disponibles et malgré une courbe d'apprentissage assez raide, la tendance actuelle est à sa simplification.
À l'opposé, web.py est quasiment l'anti-framework. Ironiquement, c'est le premier framework que j'ai découvert (probablement grâce à Simon) et qui m'a fait entrevoir l'étendue des possibilités offertes par Python dans le développement web. À l'origine, un seul fichier était nécessaire pour faire tourner une application, aujourd'hui ce framework a évolué mais il est toujours aussi simpliste/minimaliste. Il est donc à mon avis déconseillé pour les développements conséquents qui seront plus rapidement réalisés via des frameworks permettant d'avoir des raccourcis à tous les niveaux. En revanche, pour comprendre comment fonctionne un framework web dans ses moindres rouages, il y a difficilement mieux (lire auparavant l'excellent article de Joe Gregorio peu aider).
Django : le tout en un fonctionnel
Je ne sais pas s'il est nécessaire de vous rappeler l'idéologie sous-jacente car j'en ai déjà parlé ici mais en gros il s'agit d'avoir un ensemble de composants cohérents entre eux, autant dans leur fonctionnalités que dans leur documentation. Tout a donc été écrit from scratch (argument supplémentaire, au début des développements les bibliothèques actuelles n'existaient pas) pour arriver à la récente version 0.96 actuelle.
Le gros avantage de Django c'est sa communauté importante (ici l'annonce de Guido y est aussi pour quelque chose à mon avis) et sa documentation (c'est quasiment un des buts initial donc ça semble normal).
Les inconvénients soulevés ne sont pas forcément tous valables à mon avis mais pour ceux qui sont indiscutables, concernent l'impossibilité réelle d'utiliser d'autres briques Python que celles définies par défaut. L'exemple donné est celui de SQLAlchemy et les arguments donnés sont bons : la branche ouverte pour gérer ce cas végète (comme beaucoup d'autres d'ailleurs).
Les vues génériques et l'administration auto-générée finissent toujours par décevoir, ce qui est logique étant donné la manière dont c'est mis en avant dans la documentation (heureusement que la situation est clarifiée dans le livre).
Il manque un dépôt centralisé d'applications. Django snippets est un excellent début en ce sens mais il faudrait pouvoir déposer des applications complètes aussi. Pour l'instant ces ressources sont éparpillées un peu partout... edit du lendemain : c'est en cours de réflexion.
Le manque de réactivité de la part de l'équipe de développement est soulevé et je suis assez d'accord sur ce point (plusieurs de mes mails sont restés lettres mortes sur la liste de diffusion). La situation est en cours d'évolution avec l'élargissement de l'équipe et c'est une bonne chose.
En conclusion, Django est tout de même un excellent framework qui a le mérite d'être fonctionnel maintenant et dont les récentes améliorations (newforms) sont prometteuses. Je ne m'étends pas plus sur django mais de nombreux points sont évoqués, preuve que l'auteur sait très bien de quoi il parle, autant pour les avantages que pour les inconvénients.
Pylons : le framework à la carte
La philosophie de Pylons est à l'opposé de celle de Django, il s'agit de laisser le choix à l'utilisateur à chacun des niveaux pour l'utilisation de la bibliothèque existante qui lui convient. Par défaut, le framework ressemble beaucoup à Ruby on Rails et si vous souhaitez essayer Python en connaissant RoR, c'est le framework qu'il vous faut.
Le gros avantage de Pylons réside donc dans sa capacité d'adaptation, un peu à la sauce UNIX : laisser le choix à l'utilisateur en proposant des utilitaires simples que l'on peut enchaîner via des pipes. Par ailleurs, il est à noter que le principal développeur est apparemment accessible ce qui est toujours intéressant.
Le problème de pouvoir utiliser autant de briques est le manque de consistance de la documentation. Et même le meilleur des frameworks est inutilisable si l'on ne sait pas s'en servir (bon ok, j'exagère un peu ;-)).
Les composants fournis par défaut sont en train de changer pour fournir une meilleure base de développement. En particulier Toscawidgets, développé par l'équipe de TurboGears, mais aussi Mako pour les templates.
Quoi qu'il en soit, Pylons est conceptuellement vraiment intéressant et sera probablement à moyen terme une solution des plus alléchantes, surtout si la réutilisation d'applications venant d'autres frameworks devient possible. Aller vers une inter-opérabilité en ce sens serait une petite révolution.
TurboGears : un framework pour les unir tous et...
La philosophie de ce framework est de prendre les meilleurs composants Python existants et de mettre la glu permettant de les lier pour arriver au framework optimal. L'idée est très bonne mais je ne suivais plus depuis quelques temps le développement de ce framework (on peut difficilement tout suivre, heureusement qu'il y a de tels articles récapitulatifs !). J'ai été vraiment très surpris d'apprendre la tournure prise par son développement.
Le concept est très bon mais et c'est là où TurboGears a échoué, il ne faut pas se tromper lorsque l'on choisit les composants initiaux, au risque de devoir tout recommencer. Et c'est ce qui arrive apparemment à ce framework, ce qui me cause un peu de soucis pour le projet actuel de Guillaume par exemple...
D'après ce que j'ai pu comprendre, la version actuelle (1.0) est gelée en attendant le développement de la v2 qui devrait voir quasiment l'ensemble des composants changés (soit de version, soit d'orientation). C'est un choix qui est difficile à prendre et qui annonce un long hiver pour TurboGears, ce qui se reflète dans le désintéressement de la part de sa communauté apparemment. Je rejoins l'avis de l'auteur dans l'idée d'un rapprochement avec Pylons qui laisserait le choix de changer aisément à l'utilisateur et qui se baserait sur certaines des bibliothèques développées spécifiquement pour TurboGears comme Toscawidgets.
En tout cas j'en reviens pas d'un tel revirement de situation, j'espère que le projet pourra tout de même se relever car c'était vraiment bien parti et ça avait dopé, entre autres, le buzz autour des frameworks web Python au début de l'année dernière. Il était alors aussi populaire que Django !
Conclusion
Django et Pylons sont deux solutions ayant fait des choix différents dans l'implémentation de leur framework mais qui sont toutes deux actuellement fonctionnelles. Le choix entre les deux se fera à mon avis en fonction de votre expérience et de votre propre avis sur leur philosophie.
Comme je le disais précédemment, le développeur est aujourd'hui confronté au difficile dilemme d'utiliser un framework adapté à ses besoins sans pouvoir connaître tous les frameworks existant en détail car ils sont trop nombreux et évoluent trop rapidement. Ne serait-ce que pour être compétent sur Django, Pylons et Ruby on Rails par exemple, c'est mission quasi-impossible... et je ne parle même pas des frameworks PHP !
Quelle solution alors ? Il ne reste plus que les drogues dures je crois Apprenez ce qui vous plaît. Vous travaillez pour un client, ok. Mais vous travaillez dans le développement web aussi pour le « fun » que ça procure de coder, n'oubliez jamais ça. Prenez du plaisir dans votre travail et arrêtez de vous prendre la tête sur le choix du framework, si vous travaillez deux fois plus rapidement car ce que vous faites vous plaît, le client sera toujours content. Et vous aussi :-).