Comparaison de TurboGears et Django, deux frameworks web Python

Entre deux traductions de tutoriels pour Django, j'ai décidé de traduire ce petit comparatif qui fait suite aux articles d'introduction à ces frameworks web publiés sur le site d'IBM (partie 1 consacrée à Django et partie 2 à TurboGears). Je trouve que c'est l'un des plus objectifs qui m'ait été donné de lire et il est à ce titre intéressant pour ceux qui sont dans le doute et/ou curieux.

Django et TurboGears sont deux frameworks de type MVC qui permettent de développer des sites Web de manière agile et rapide en utilisant le langage Python. De façon à choisir celui qui répondra le mieux à vos besoins, voici quelques différences à connaître :

Historique

Les deux projets, tout comme Ruby on Rails, sont issus d'applications existantes ayant été ensuite « libérées » pour la communauté Open Source. Django est plus vieux et provient, à la base, d'un journal en ligne qui sert des millions de pages par jour. TurboGears est issu du développement d'un client riche, une application de lecture de flux RSS qui est toujours en développement. Par rapport à Django, TurboGears est davantage guidé par la communauté car il utilise de nombreux composants open-source pré-existants.

Les origines différentes de chaque projet ont mené à des priorités différentes lors du développement. L'équipe de Django, venant du monde en constante évolution du journalisme en ligne, s'est focalisée sur un framework permettant de bâtir rapidemment des applications facilement modifiables et basées sur du contenu. L'équipe de TurboGears, avec ses origines de produit-consommateur, s'est dirigée vers des applications client riches et une architecture modulaire.

URLs

Le mécanisme de gestion des requêtes de Django correspond aux contrôleurs de classes et aux noms de méthodes. Dès que vous ajoutez une nouvelle classe ou une nouvelle méthode, la nouvelle URL est immédiatement disponible. Si vous avez besoin de changer le chemin qui execute un contrôleur donné, vous devez modifier la structure de votre code. Réciproquement, Django utilise un fichier de configuration indépendant basé sur des expressions rationnelles. Celui-ci fait correspondre les URLs au code, découplant la structure des URLs de l'implémentation.

Le système de TurboGears est plus rapide à mettre en place que celui de Django, puiqu'il ne nécessite qu'un simple décorateur pour rendre les nouvelles pages disponibles. Par contre, le système de configuration de Django permet un contrôle et une flexibilité totale. Les URLs de Django peuvent être facilement rétablies pour une application après un réarrangement majeur du code. Cela permet de prévenir les liens morts causés par les anciens favoris ou le cache des moteurs de recherche. Les liens morts sont à l'origine d'une baisse du traffic et de l'utilisabilité des sites basés sur du contenu auxquels Django est destiné.

Réutilisation du code

L'équipe de TurboGears appelle leur projet un méga-framework pour rendre limpide le fait que TG est issu de composants existants. L'équipe de TurboGears sélectionne et incorpore le meilleur code source diponible au lieu de tout réécrire à partir de rien. L'un des bénéfice du framework TurboGears est, qu'étant un méga-projet, il dispose d'une méga-communauté. TG est devenu un puissant catalyseur, augmentant l'intérêt et la motivation pour les projets formant le cœur de TurboGears.

À l'inverse, Django a été créé en 2003 lorsque l'état des composants Python existants n'était pas aussi avancé que ce qu'il est aujourd'hui. Le framework Django a été créé à partir de rien, et le resultat est un framework stable qui est utilisé pour de nombreux sites qui gèrent des millions de clics par jour. Toutefois, certains avancent que le projet Django souffre du syndrome du NIH (réinvention de la roue) en raison de son manque de réutilisation du code. La position de l'équipe de Django est que le travail nécessaire pour créer un framework en Python à partir de rien n'est pas plus important que celui d'adapter les composants existants ensemble et que le résultat est un framework uniformisé et cohérent.

JavaScript

TurboGears a donné à la bibliothèque JavaScript MochiKit une position de premier choix au sein de son framework. L'équipe a aussi créé une bibliothèque de composants qui permet l'utilisation étendue du JavaScript pour créer des éléments d'interfaces « enrichies ». Cela montre l'importance attribuée au développement de clients riches (Ajax) dans le monde de TurboGears. L'équipe de Django n'a pas choisie de bibliothèque JavaScript particulière inclue dans leur framework par défaut mais a discuté de cette possibilité (NdT : c'est toujours en cours de discussion). Aucun des projets ne vous restreint, d'aucune façon que ce soit, à utiliser la bibliothèque JavaScript de votre choix.

Outils d'administration

Les deux projets ont une interface d'administration. L'outil d'aministration de Django est destiné à l'utilisateur final qui a besoin d'une interface ergonomique d'insertion des données ne nécessitant pas d'être modifiée à chaque ajout de nouvelle fonctionnalité. En revanche, l'outil d'aministration de TurboGears est destiné aux développeurs. Elle leur permet d'avoir accès à divers outils dont un visualisateur et un éditeur de base de données basiques.

Licence

Du fait que Django soit parti de rien, l'intégralité du projet est sous une unique licence open source (le licence BSD). TurboGears, issu de plusieurs projets, a plusieurs licences. SQLObject, l'outil d'ORM, est protégé par la LGPL, qui stipule que chaque modification directe de SQLObject doit être restituée à la communauté du projet. La licence ne nécessite pas que les application l'utilisant soient open source. Néanmoins, certaines sociétés n'acceptent pas l'utilisation de logiciels sous LGPL. Dans ce cas, vous pouvez utiliser SQLAlchemy, un autre outil d'ORM bénéficiant d'un support important au sein de la communauté de TG.

Exemples concrêts

Consultez la liste des sites propulsés par Django et TurboGears. Ces applications en ligne témoignent de ce qui peut être fait avec chacun de ces outils.

Bonus

On n'est plus dans la traduction mais si vous vous intéressez aussi à RoR je vous recommande cette vidéo qui date un peu (donc les exemples sont légèrement obsolètes) mais qui se termine par une séance de questions/réponses intéressante et plutôt marrante (pour les geeks). De toute façon, maintenant qu'on sait que Django est plus performant que Rails... je ne vois plus trop d'intérêt à apprendre le ruby ;-).