larlet-fr-david/david/biologeek/archives/20060921-encore-une-comparaison-django-ruby-on-rails-les-deux-frameworks-web-qui-buzzent/article.md

title: Encore une comparaison Django/Ruby on Rails, les deux frameworks web qui buzzent slug: encore-une-comparaison-django-ruby-on-rails-les-deux-frameworks-web-qui-buzzent date: 2006-09-21 14:52:38 type: post vignette: images/logos/frameworks_web.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: ★ Astuces et bonnes pratiques Django contextual_url2: 20080211-astuces-et-bonnes-pratiques-django contextual_title3: Des vacances et des liens contextual_url3: 20071007-des-vacances-et-des-liens

Voila une discussion qui revient souvent sur la mailing-list de Django et Jeff Rodenburg a regroupé les réponses les plus pertinentes dans un même mail (pour comprendre la suite, ce sont des réponses à des nouveaux venus). N'ayant pas assez d'expérience avec Ruby on Rails, je préfère m'en tenir à la traduction des arguments de vétérans. Il y a bien sûr un certain parti pris et je serais intéressé par le même style de résumé provenant de la mailing-list RoR, je suis sûr que la question doit être fréquemment posée aussi... pas forcément avec les mêmes arguments en retour.

L'avis de Jeff Rodenburg

Quelques observations d'un vétéran du développement découvrant ces deux frameworks :

• Déploiement de Rails face au déploiement de Django : Django semble bénéficier d'un plus dans cette colonne alors que Rails est un point d'interrogation. Apache2/Mongrel est la solution préconisée, mais ça reste une version qui doit faire ses preuves. J'ai récemment eu affaire à un déploiement d'une application Rails et de ce point de vue, Rails n'est pas mature. Heureusement, Django peut être déployé avec mod_python, ce qui est moins contraignant.

• Ma perception au sujet de la documentation n'est qu'une perception. La communauté Rails a à sa disposition des livres, ce qui la distingue pour le moment. L'édition de leur site est suspecte, bien que certaines pages au sujet de l'installation ou du déploiement soient convenables. Si je peux faire une suggestion à la communauté Django, ce serait de développer davantage la documentation pour que quelqu'un comme moi puisse un peu mieux prendre en main le système lors de la découverte.

• Integration v2.0 : c'est un nom générique que je donne à chaque application qui évolue après sa première mise en production. Je place Rails dans la catégorie des mentalités monolithiques, ce qui est surprenant compte tenu de ce qui est annoncé. D'après mon expérience, passée une certaine taille, un système n'a jamais évité une itération où vous êtes confrontés à l'accès/la modification des données en dehors des constructions originales, c.-à-d. une couche données séparée. Je ne sais pas sûr de savoir si c'est réalisable avec l'architecture de Django mais les ressources de Rails pour procéder à cette intégration son inexistantes.

• La structure de template (dont je ne connais pas tous les détails) est problématique pour moi. Nous avons vu que la présentation est en rapport avec les templates. Peut-être que c'est juste une question de préférences mais j'apprécie le fait que Django conserve la vue séparée du template.

Si mon avis est biaisé en faveur de Django, c'est en partie en raison de ma préférence pour Python mais aussi de mon dédain pour le jihad Rails qui ne cesse d'enfler. Pour être totalement honnête, je suis du midwest. Comment est ce que je peux ne pas être en accord avec quelquechose sortant de Lawrence, KS ? ;-)

L'avis de Sean Schertell

Je suis passé de Django à Rails et depuis je m'éclate.

Mais ça dépend vraiment de ce dont vous avez besoin. Si vous développez une seule application monolithique, Rails est très bon. J'ai réalisé une énorme application de facturation/comptabilité pour une compagnie d'assurance avec Rails. Elle prend en charge des dizaines de milliers de membres et traite plus d'un million de dollars de transactions par mois à travers un processus atrocement complexe de facturation. À mon avis, Rails est parfait pour ce genre de choses. Je suis sûr que j'aurais pu faire la même chose avec Django mais Rails semble un peu mieux adapté à ce type de choses : de grosses et uniques applications. L'inclusion d'ajax nativement est très pratique aussi. Et la syntaxe Ruby est un réel plaisir à utiliser (même si je suis définitivement fan de Python).

Mais je considère qu'il y a des inconvénients à Rails, voici les raisons pour lesquelles j'ai changé :

• les applications Rails ne sont pas portables. Du tout. Pas seulement un peu. Pour ma part, je ne passe pas mon temps à réaliser des applications de facturation pour des assurances. Je développe principalement des sites internet composés de petites applications comme une gallerie photo, un blog ou un panier d'achat. Avec Django, vous pouvez créer une appli, la placer sur un serveur quelquepart, et pour autant de sites (projets) que vous le désirez, vous pouvez prendre cette appli, la styler et l'utiliser. Avec Rails, il n'y a pas de concept « d'appli » pouvant être importées au sein de « projets ». Il n'y a qu'une énorme appli qui est votre projet. Pour du développement web, ça craint.

• les applications Rails sont un peu délicates à déployer. J'ai entendu dire que Apache2/Mongrel est sur le point de résoudre ce problème. Mais la méthode standard de déploiement des applis Rails est d'utiliser Lighttpd avec FastCGI en passant par Apache. C'est pas simple et parfois le processus FastCGI s'emballe et utilise toute vos ressources jusqu'à ce que vous tuyez chaque processus. Le déploiement typique de Django utilise Apache/mod_python. C'est rapide, stable et facile à déployer.

• La documentation !!! Je suis surpris que tu mentionnes ça comme étant un avantage de Rails. C'est l'une des rares choses que je trouve vraiment frustrante avec Rails. Les docs sont justes inexistantes. Bien sûr tu peux googler des tutoriels ou acheter le « Agile book » (qui est excellent au passage). Mais la documentation actuelle du site de Rails est horrible. La plupart des gens participent au wiki, certaines d'entre elles étant dépassées ou même fausses, et il y a d'énormes manques. La documentation Django est l'une des choses qui m'a remis sur la bonne route. Cherchant une alternative à Rails, lorsque j'ai vu la partie documentation du site, ce fût une réelle bouffée d'air frais. Ahhhhh... c'est donc ainsi qu'une documentation devrait être :-)

Passons maintenant de l'autre côté :

Il y a quelques trucs dans Django qui ne sont pas parfaits.

• l'interface d'administration est un piège. La partie administration est incroyablement géniale lorsqu'elle correspond exactement à vos besoins. Mais si vous décidez, pour une raison quelconque, de faire votre partie administration personnalisée, apprêtez vous à lutter. Par exemple, une identification basique. Vous pouvez utiliser le système d'identification inclus, mais dans ce cas vous allez devoir écrire en dur les urls pour les pages de login/logout. Vous n'aimez pas ces urls ? Dans ce cas, il va vous falloir écrire votre propre système d'identification à partir de rien. Je me suis aperçu que c'était le cas pour de nombreuses choses. Django vous permet d'avoir quelques trucs en natif, mais ce n'est pas aussi flexible que ce que j'aurais voulu. Et réécrire à partir de rien m'a demandé plus de travail que ce que cela avait aurait été le cas avec Rails (par exemple pour l'identification).

• pas d'ajax. Rien ne vous empêche d'utiliser prototype ou dojo ou autre. Mais je dois avouer que la manière de faire de l'ajax avec Rails me manque, d'autant qu'il est aussi possible de s'en passer aisément.

Un dernier point au sujet des besoins et des finitions : peut-être la plus grosse surprise lorsque j'ai découvert Django, c'est le degré de finition du framework. Rails et Django sont très similaires dans leur catégorie à mon avis. Pour être honnête, je m'attendais à trouver Django un peu moins performant sur certains aspects et ce n'est pas du tout le cas. C'est très robuste, bien documenté et ça fonctionne très très bien. La communauté est géniale aussi. Django est vraiment un cran au dessus par rapport à Rails pour ce qui est de la finition.

L'avis de Russell Keith-Magee

Disclaimer : je suis un développeur Django. J'ai étudié à Rais avant de m'impliquer avec Django, et je « jette un œil » occasionnellement mais je n'ai pas une expérience significative avec Rails. Je peux me tromper sur certains points, donc n'hésitez pas à me corriger.

Vous avez raison lorsque vous dites que Rails et Django sont très semblables. L'évènement Snakes vs Rubies l'année dernière a confirmé le fait que Django et Rails ont des buts similaires - ils servent à développer rapidemment des applications aussi facilement que possible, dans le but de rendre l'usuel trivial et le spécifique possible. Le serveur en rechargement permanent, la facilité à arriver à un « hello world » et l'utilisation de langages avec des capacités importantes d'introspection sont des fonctionnalités communes aux deux frameworks.

Je suis sûr que d'autres avanceront d'autres opinions mais voici ma vision des différences.

• (Évidemment) Python/Ruby. Ce n'est pas une raison sérieuse de choix mais ça peut faire la différence.

• Design de la base de données. Rails commence par vous faire définir une table SQL dans votre base de données, puis écrit le modèle qui reflète l'état du SQL. Si vous modifiez une table dans votre base, votre modèle change pour réfleter ce changement. Django commence par la définiton de votre modèle, puis s'occupe de créer les tables reflétant ce modèle. Il y a actuellement un projet Google SoC gérant les problèmes de migration du schéma lors des changements du modèle. Qu'est ce qui est le mieux ? Je préfère l'approche de Django, car pour un nouveau projet, je n'ai pas besoin d'écrire la même définition deux fois (j'ai assez écrit de C++ dans ma vie pour ne jamais plus avoir envie de réitérer ça :-). J'ai souvent lu que l'approche Rails était plus intéressante lorsque l'on veut partir d'une base existante. Je n'ai pas eu à le faire mais Django peut se baser sur une base existante, la définition des modèles est suggérée et la création des tables est alors sautée si nécessaire.

• l'interface d'administration. Rails est un échaffaudage, mais vous devez quand même écrire au moins quelques templates pour avoir une interface de gestion. Chaque application Django a une interface de gestion incluse. Il y a des extensions de Rails permettant d'avoir la même fonctionnalité, mais elles ne sont pas inclues.

Pour moi c'est un sérieux avantage. Les utilisateurs finaux ne devraient jamais voir l'interface d'administration. Mais en termes de création de projet je trouve l'interface d'administration inestimable. Elle permet de vérifier si vos modèles sont corrects en insérant quelques données de test pour valider vos vues en cours de développement. De plus, toutes les données utilisées dans l'interface d'admin sont aussi accessibles à l'utilisateur final par l'intermédiaire de leurs propres vues.

Mon avis

Bon finalement je ne peux pas m'en empêcher ;-). Vous aurez noté la différence de niveau de ces trois témoignages (même après traduction on sent toujours que le premier est un peu aigri...). Quelques précisions :

• l'interface d'administration ne doit pas être considérée comme étant destinée aux utilisateurs, elle sert à administrer votre projet comme son nom l'indique et c'est vraiment très pratique pour développer ;
• pour la documentation, aucun des comparatifs ne parle du prochain livre sur Django qui devrait sortir en Octobre (en fait probablement plus tard, il faut que la 1.0 soit sortie avant) ;
• pour moi, Django est vraiment lié à la publication. Ça fait très 1.0 de dire ça mais c'est 90% du web quand même :-).

Et vous, pourquoi appréciez vous Django et/ou Rails ?