> c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique
La force de Django est de proposer effectivement un framework cohérent donc plus facile à apprendre, une documentation centralisé etc... mais c'est également sa plus grande faiblesse.
* les composants Django pris séparément sont pas toujours au niveau de la concurrence, je pense entre autre au Django ORM (une bouze extrêmement limité comparé à SQLAlchemy ou Storm) ou au module d'authentification.
* la difficulté à utiliser un composant tiers comme un autre ORM ou moteur de templates.
* c'est quasiment le seul framework web Python qui ne supporte PAS la norme WSGI ! Je ne parle pas de la capacité à être servi par un serveur WSGI mais de la possibilité de chainer les middlewares. Django se prive de la possibilité d'utiliser des composants éprouvés notamment pour l'authentification, le caching etc ... Certes, il y a les apps (l'équivalent côté pylons/TG serait plus ou moins les widgets du projet ToscaWidgets qui est en retrait par rapport aux Django Apps) pour permettre la réutilisabilité du code, mais ça reste un mécanisme limité.
* quelques bizarreries: gestion des settings
* aucune attention porté aux performances qui ne cessent de diminuer au fur et à mesure des versions, si je veux un site qui monte en échelle (genre Sourceforge), je peux oublier Django.
* la communauté Django est très active et amicale, les core developers not so much ...
Je pourrais faire une liste aussi longue pour Pylons/TG, tout ça pour dire que le choix d'un framework web python n'est pas aussi évident.
Si je suis un développeur web qui souhaite proposer à ses clients des sites riches avec un TTM le plus réduit possible, je m'orienterais naturellement vers Django, je suis un développeur Python chevronné mais qui n'a pas forcément fait du web, je m'orienterais vers Pylons/TG qui me permettra de réutiliser mes connaissance, je veux un framework minimaliste, j'utiliser un micro-framework (ie: Flask/Jinja2, web.py, repoze.bfg, etc ...) ou même une boite à outils comme werkzeug !
> c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique, à fusionner ou forker dans tous les sens.
Les fusions ont toujours été soigneusement réfléchies et résultent toujours d'une convergence des roadmaps des développeurs. Pourquoi réinventer la roue à chaque fois ?
Mis à part le passage de TG1 -toujours maintenu actuellement- à TG2, il n'y a pas plus d'incompatibilités lors des changements de versions chez Pylons ou TG qu'avec Django.
Dans le cas de Pyramid:
* porter une application Pylons à Pyramid ça va de "rien à faire" à "quelques changements mineurs qui peuvent être automatisés". Un outil de migration est prévu d'ailleurs.
* pour les applications repoze.bfg, mis à part le changement de nom et une réorganisation des modules, y a rien à faire.
* j'ai ouï dire qu'il a fallu moins d'une journée pour avoir un prototype fonctionnel de "TG3" et qu'une application TG2 pouvait tourner quasiment sans modifications dessus.
Certes, le schéma de migration de Django est certainement mieux contrôlé, mais rien de catastrophique non plus. De plus, les fusions permettent justement de limiter ces problèmes.
Quant aux forks, ils sont assez peu nombreux et pour la plupart confidentiels.
> pas d'avoir une architecture top-moumoute avec des composants décentralisés et des buzzwords hérités du monde Java.
Même si Pyramid est un lointain descendant de Zope à travers repoze.bfg (c'est bien, ça va donner matière à troller lors des afpyros), la réputation de lourdeur que se traine Zope ne se justifie plus du tout pour les composants repoze issus de la restructuration de Zope en middlewares WSGI.
[^] # Re: La validité de la ZCA
Posté par GeneralZod . En réponse à la dépêche Pylons et repoze.bfg fusionnent pour donner Pyramid. Évalué à 5.
Pylons/TG aussi.
> c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique
La force de Django est de proposer effectivement un framework cohérent donc plus facile à apprendre, une documentation centralisé etc... mais c'est également sa plus grande faiblesse.
* les composants Django pris séparément sont pas toujours au niveau de la concurrence, je pense entre autre au Django ORM (une bouze extrêmement limité comparé à SQLAlchemy ou Storm) ou au module d'authentification.
* la difficulté à utiliser un composant tiers comme un autre ORM ou moteur de templates.
* c'est quasiment le seul framework web Python qui ne supporte PAS la norme WSGI ! Je ne parle pas de la capacité à être servi par un serveur WSGI mais de la possibilité de chainer les middlewares. Django se prive de la possibilité d'utiliser des composants éprouvés notamment pour l'authentification, le caching etc ... Certes, il y a les apps (l'équivalent côté pylons/TG serait plus ou moins les widgets du projet ToscaWidgets qui est en retrait par rapport aux Django Apps) pour permettre la réutilisabilité du code, mais ça reste un mécanisme limité.
* quelques bizarreries: gestion des settings
* aucune attention porté aux performances qui ne cessent de diminuer au fur et à mesure des versions, si je veux un site qui monte en échelle (genre Sourceforge), je peux oublier Django.
* la communauté Django est très active et amicale, les core developers not so much ...
Je pourrais faire une liste aussi longue pour Pylons/TG, tout ça pour dire que le choix d'un framework web python n'est pas aussi évident.
Si je suis un développeur web qui souhaite proposer à ses clients des sites riches avec un TTM le plus réduit possible, je m'orienterais naturellement vers Django, je suis un développeur Python chevronné mais qui n'a pas forcément fait du web, je m'orienterais vers Pylons/TG qui me permettra de réutiliser mes connaissance, je veux un framework minimaliste, j'utiliser un micro-framework (ie: Flask/Jinja2, web.py, repoze.bfg, etc ...) ou même une boite à outils comme werkzeug !
> c'est précisément parce qu'ils ne passent pas leur temps à changer de plateforme technique, à fusionner ou forker dans tous les sens.
Les fusions ont toujours été soigneusement réfléchies et résultent toujours d'une convergence des roadmaps des développeurs. Pourquoi réinventer la roue à chaque fois ?
Mis à part le passage de TG1 -toujours maintenu actuellement- à TG2, il n'y a pas plus d'incompatibilités lors des changements de versions chez Pylons ou TG qu'avec Django.
Dans le cas de Pyramid:
* porter une application Pylons à Pyramid ça va de "rien à faire" à "quelques changements mineurs qui peuvent être automatisés". Un outil de migration est prévu d'ailleurs.
* pour les applications repoze.bfg, mis à part le changement de nom et une réorganisation des modules, y a rien à faire.
* j'ai ouï dire qu'il a fallu moins d'une journée pour avoir un prototype fonctionnel de "TG3" et qu'une application TG2 pouvait tourner quasiment sans modifications dessus.
Certes, le schéma de migration de Django est certainement mieux contrôlé, mais rien de catastrophique non plus. De plus, les fusions permettent justement de limiter ces problèmes.
Quant aux forks, ils sont assez peu nombreux et pour la plupart confidentiels.
> pas d'avoir une architecture top-moumoute avec des composants décentralisés et des buzzwords hérités du monde Java.
Même si Pyramid est un lointain descendant de Zope à travers repoze.bfg (c'est bien, ça va donner matière à troller lors des afpyros), la réputation de lourdeur que se traine Zope ne se justifie plus du tout pour les composants repoze issus de la restructuration de Zope en middlewares WSGI.