Mais bon, je ne cherche pas à convaincre, c'est juste mon expérience après avoir étudié et essayé les deux.
Je ne doute pas que ton expérience soit intéressante, mais tu donnes peu de détails sur cette dernière qui permettrait de donner une idée de son aspect universel (si tu l'as expérimentée sur 12 applis de 500K lignes dans 5 langages, ce n'est pas pareil que 3 applis de 150 lignes dans 1 langage), tout en balançant des généralités ("les micro-frameworks c'est mieux sur le long terme").
Personnellement je bosse quotidiennement sur une application en Django depuis 2009 (et le prototype date de 2007), et la maintenance n'est pas un problème, sachant qu'on a commencé avant la 1.0, et qu'on utilise actuellement la 1.8. Il nous arrivent régulièrement d'atteindre les limites du framework, et je ne veux absolument pas à dire qu'il est parfait (non il est même très perfectible) ni lui faire spécialement de publicité (il n'en a pas besoin, et des tas d'outils de qualité bénéficient de moins de visibilité). Mais au final ce qui me limite le plus c'est mon propre code, et les quelques problèmes techniques que me posent le framework sont complètement anecdotiques par rapport à tout ce qu'il peut m'apporter par ailleurs.
Maintenant j'admets tout à fait que dans l'absolu le design monolithique de Django est moins élégant que le design d'un Pyramid par exemple; et je suis content qu'il existe des alternatives à la philosophie différente. Mais en l'occurrence Pyramid n'existait pas quand on a commencé le projet (je ne sais plus si Pylons existait à l'époque) ; je serai bien incapable de dire ce qui se serait passé si on avait utilisé autre chose (il faudrait une machine à voyager dans le temps pour ça), mais vu que Django a évolué de manière efficace (en cassant des choses quand il le fallait, mais en essayant de rendre les cassures les moins pénibles possibles), je doute que les choses auraient pu se passer beaucoup mieux.
[^] # Re: Go
Posté par GuieA_7 (site web personnel) . En réponse au journal Et si JavaScript allait droit dans le mur ?. Évalué à 4.
Je ne doute pas que ton expérience soit intéressante, mais tu donnes peu de détails sur cette dernière qui permettrait de donner une idée de son aspect universel (si tu l'as expérimentée sur 12 applis de 500K lignes dans 5 langages, ce n'est pas pareil que 3 applis de 150 lignes dans 1 langage), tout en balançant des généralités ("les micro-frameworks c'est mieux sur le long terme").
Personnellement je bosse quotidiennement sur une application en Django depuis 2009 (et le prototype date de 2007), et la maintenance n'est pas un problème, sachant qu'on a commencé avant la 1.0, et qu'on utilise actuellement la 1.8. Il nous arrivent régulièrement d'atteindre les limites du framework, et je ne veux absolument pas à dire qu'il est parfait (non il est même très perfectible) ni lui faire spécialement de publicité (il n'en a pas besoin, et des tas d'outils de qualité bénéficient de moins de visibilité). Mais au final ce qui me limite le plus c'est mon propre code, et les quelques problèmes techniques que me posent le framework sont complètement anecdotiques par rapport à tout ce qu'il peut m'apporter par ailleurs.
Maintenant j'admets tout à fait que dans l'absolu le design monolithique de Django est moins élégant que le design d'un Pyramid par exemple; et je suis content qu'il existe des alternatives à la philosophie différente. Mais en l'occurrence Pyramid n'existait pas quand on a commencé le projet (je ne sais plus si Pylons existait à l'époque) ; je serai bien incapable de dire ce qui se serait passé si on avait utilisé autre chose (il faudrait une machine à voyager dans le temps pour ça), mais vu que Django a évolué de manière efficace (en cassant des choses quand il le fallait, mais en essayant de rendre les cassures les moins pénibles possibles), je doute que les choses auraient pu se passer beaucoup mieux.