davidbgk
/
larlet-fr-david

<!doctype html>
<html lang=fr>
<head>
  <!-- Always define the charset before the title -->
  <meta charset=utf-8>
  <title>Encore une comparaison Django/Ruby on Rails, les deux frameworks web qui buzzent — Biologeek — David Larlet</title>
  <!-- Define a viewport to mobile devices to use - telling the browser to assume that the page is as wide as the device (width=device-width) and setting the initial page zoom level to be 1 (initial-scale=1.0) -->
  <meta name="viewport" content="width=device-width, initial-scale=1"/>
  <!-- Fake favicon, to avoid extra request to the server -->
  <link rel="icon" href="data:;base64,iVBORw0KGgo=">
  <link type="application/atom+xml" rel="alternate" title="Feed" href="/david/log/" />
  <link rel="manifest" href="/manifest.json">
  
  <link rel="stylesheet" href="/static/david/css/larlet-david-_J6Rv.css" data-instant-track />
  
  <noscript>
    <style type="text/css">
      /* Otherwise fonts are loaded by JS for faster initial rendering. See scripts at the bottom. */
      body {
        font-family: 'EquityTextB', serif;
      }
      h1, h2, h3, h4, h5, h6, time, nav a, nav a:link, nav a:visited {
        font-family: 'EquityCapsB', sans-serif;
        font-variant: normal;
      }
    </style>
  </noscript>
  
  <!-- Canonical URL for SEO purposes -->
  <link rel="canonical" href="https://larlet.fr/david/biologeek/archives/20060921-encore-une-comparaison-django-ruby-on-rails-les-deux-frameworks-web-qui-buzzent">

</head>
<body>
  <div>
    
    <header>
      <nav>
        <p>
          <small>
            Je suis <a href="/david/" title="Profil public">David Larlet</a>, <a href="/david/pro/" title="Activité professionnelle">artisan</a> du web qui vous <a href="/david/pro/accompagnement/" title="Activité d’accompagnement">accompagne</a><span class="more-infos"> dans l’acquisition de savoirs pour concevoir des <a href="/david/pro/produits-essentiels/" title="Qu’est-ce qu’un produit essentiel ?">produits essentiels</a></span>. <span class="more-more-infos">Discutons ensemble d’une <a href="/david/pro/devis/" title="En savoir plus">non-demande de devis</a>.</span> Je partage ici mes <a href="/david/blog/" title="Expériences bienveillantes">réflexions</a> et <a href="/david/correspondances/2017/" title="Lettres hebdomadaires">correspondances</a>.
          </small>
        </p>
      </nav>
    </header>
    
    
  <section>
    <h1 property="schema:name">Encore une comparaison Django/Ruby on Rails, les deux frameworks web qui buzzent</h1>
    <article typeof="schema:BlogPosting">
      <div property="schema:articleBody">
        <img src="/static/david/biologeek/images/logos/frameworks_web.png" alt="vignette" style="float:left; margin: 0.5em 1em;" property="schema:thumbnailUrl" />
        <p>Voila une discussion qui revient souvent sur la mailing-list de Django et Jeff Rodenburg a <a href="http://groups.google.com/group/django-users/browse_frm/thread/c59a3b4e1fb9cae7/4621f580a6386c02?lnk=st&amp;rnum=2#4621f580a6386c02">regroupé les réponses les plus pertinentes dans un même mail</a> (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.</p>

<h2>L'avis de Jeff Rodenburg</h2>

<p>Quelques observations d'un vétéran du développement découvrant ces deux frameworks&nbsp;:</p>

<ul>
<li>Déploiement de Rails face au déploiement de Django&nbsp;: 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.</li>
</ul>

<ul>
<li>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.</li>
</ul>

<ul>
<li>Integration v2.0&nbsp;: 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.</li>
</ul>

<ul>
<li>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.</li>
</ul>

<p>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&nbsp;? ;-)</p>

<h2>L'avis de Sean Schertell</h2>

<p>Je suis passé de Django à Rails et depuis je m'éclate.</p>

<p>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&nbsp;: 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).</p>

<p>Mais je considère qu'il y a des inconvénients à Rails, voici les raisons pour lesquelles j'ai changé&nbsp;:</p>

<ul>
<li>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 «&nbsp;d'appli » pouvant être importées au sein de «&nbsp;projets ». Il n'y a qu'une énorme appli qui <strong>est</strong> votre projet. Pour du développement web, ça craint.</li>
</ul>

<ul>
<li>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.</li>
</ul>

<ul>
<li>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 «&nbsp;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 <strong>ainsi</strong> qu'une documentation devrait être :-)</li>
</ul>

<p>Passons maintenant de l'autre côté&nbsp;:</p>

<p>Il y a quelques trucs dans Django qui ne sont pas parfaits.</p>

<ul>
<li>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&nbsp;? 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).</li>
</ul>

<ul>
<li>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.</li>
</ul>

<p>Un dernier point au sujet des besoins et des finitions&nbsp;: 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.</p>

<h2>L'avis de Russell Keith-Magee</h2>

<p>Disclaimer&nbsp;: je suis un développeur Django. J'ai étudié à Rais avant de m'impliquer avec Django, et je «&nbsp;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.</p>

<p>Vous avez raison lorsque vous dites que Rails et Django sont très semblables. L'<a href="http://www.djangoproject.com/snakesandrubies/">évènement Snakes vs Rubies</a> 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 «&nbsp;hello world » et l'utilisation de langages avec des capacités importantes d'introspection sont des fonctionnalités communes aux deux frameworks.</p>

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

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

<ul>
<li>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&nbsp;? 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.</li>
</ul>

<ul>
<li>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.</li>
</ul>

<p>Pour moi c'est un sérieux avantage. Les utilisateurs finaux ne devraient <strong>jamais</strong> 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.</p>

<h2>Mon avis</h2>

<p>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&nbsp;:</p>

<ul>
<li>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&nbsp;;</li>
<li>pour la documentation, aucun des comparatifs ne parle du <a href="http://www.apress.com/book/bookDisplay.html?bID=10176">prochain livre sur Django</a> qui devrait sortir en Octobre (en fait probablement plus tard, il faut que la 1.0 soit sortie avant)&nbsp;;</li>
<li>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 :-).</li>
</ul>

<p>Et vous, pourquoi appréciez vous Django et/ou Rails&nbsp;?</p>
      </div>
    </article>
    <footer>
      <h6 property="schema:datePublished">— 21/09/2006</h6>
    </footer>
  </section>
  <section>
    <div>
      <h3>Articles peut-être en rapport</h3>
      <ul>
        <li><a href="/david/biologeek/archives/20080902-sortie-de-django-10-une-annee-de-nouveautes/" title="Accès à Sortie de Django 1.0, une année de nouveautés">Sortie de Django 1.0, une année de nouveautés</a></li>
        <li><a href="/david/biologeek/archives/20080211-astuces-et-bonnes-pratiques-django/" title="Accès à ★ Astuces et bonnes pratiques Django">★ Astuces et bonnes pratiques Django</a></li>
        <li><a href="/david/biologeek/archives/20071007-des-vacances-et-des-liens/" title="Accès à Des vacances et des liens">Des vacances et des liens</a></li>
      </ul>
    </div>
  </section>
  <section>
    <div id="comments">
      <h3>Commentaires</h3>
      
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Noé</span> le <span class="comment-date" property="schema:commentTime">21/09/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Beuuuh, Nitro c'est mieux.<br />
Voir les screencasts sur cette page :<br />
<a href="http://www.nitroproject.org/documentation" title="http://www.nitroproject.org/documentation" rel="nofollow">www.nitroproject.org/docu...</a><br />
<br />
<br />
Par rapport à Rails, c'est carrément plus flexible et, je trouve, plus intuitif.<br />
(Notamment leur ORM, Og, est excellent)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Frédéric de Villamil</span> le <span class="comment-date" property="schema:commentTime">22/09/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>J'aurais aimé, dans un monde idéal, que tu ne fasses pas seulement parler des pythonistes convaincus passés à Ruby, mais aussi des rubyistes convaincus s'étant un moment égarés dans les méandres de python, pour savoir ce qu'ils avaient à en dire.<br />
Ton article m'aurait semblé moins biaisé mjdcjdr.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Black Pignouf</span> le <span class="comment-date" property="schema:commentTime">24/09/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Je n'ai toujours pas trouvé de comparaisons objectives Django/Rails, mais pour ce qui est du premier avis, c'est vraiment du f....age de g....le!<br />
<br />
Enfin bon, merci quand même d'avoir traduit tout ça!</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">25/09/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Frédéric : comme je l'ai dit en introduction, il me suffit d'un lien ;-)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">NiCoS</span> le <span class="comment-date" property="schema:commentTime">25/09/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Pour avoir lu le bouquin sur Rails, force est de constater qu'il donne plus envie que la doc actuelle sur Django. Par contre, comme a pu me le montrer Niko, des pans entiers ne sont plus à jour (par ex dans le bouquin, on gère soit même ses bases, alors qu'il existe maintenant un utilitaire comme dans Django pour faire de la création de bases à partir d'une classe).<br />
<br />
Comme j'ai pu le dire précédemment, le tutoriel est django est pas à la mesure du framework je pense. A ce jour, je serais donc plus pro-rails que pro-django juste pour la partie doc...<br />
<br />
Ensuite, django avait l'air plus orienté publication, alors que rails est plus orienté application, donc est-ce que cela a un réel sens de les comparer ? ne vaudrait-il pas mieux comparer rails à turbogears par ex ? A moins que ce ne soit pas hype et faire du buzz de parler de turbogears ;-D</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">EL AATIFI Sidi Mohamed</span> le <span class="comment-date" property="schema:commentTime">21/10/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>J'utilise du python, c'est un vrai plaisir Django me permet de faire les choses plus rapidement, et plus &quot;Clean&quot;.<br />
Et j'ai aussi utilise Ruby plus liberal plus pragmatique, encore plus de productivite. Mais je suis sure qu'il y a une raison deriere l'existance de Python et de Django .. et un autre besoin deriere Ruby/Rails c'est au developpeur,et  au pro d'avoir un oeil critique sur la technologie, d'examiner le besoin et en consequant  chosir l'outil adequat, loin de tout fanatisme !!</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">dl.zerocool</span> le <span class="comment-date" property="schema:commentTime">26/10/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Bonjour,<br />
Après une lecture attentive de vos commentaires,<br />
je ne peux que vous donnez raisons à tous.<br />
<br />
Je suis un dev. ruby(ror), c/c++, python et php. Ruby est donc pour moi l'outil adéquat pour faire des sites web tournés applications.<br />
En ce qui concerne la documentation Django et ROR on tous les deux un immense trou. En réalité celà serait plutôt un fossé en ce moment. Bien que de nouveau livres et de nouvelles édition (mise à jour) sortent ou vont sortir pour rails. J'en attend toujours un peu plus pour Django.<br />
<br />
Pour moi un site web est une application, je ne travail pas dans le domaine de la publication simple tel que les blogs, simple page de news ou encore d'autre. Je suis asser daccord avec les autres commentaires, précisant que Django serait plus adéquat pour la publication. Heureusement ror commence à rattraper le coup en rendant sont travail plus portable ainsi que apache2/mongrel qui viennent nous simplifier la tâche.<br />
<br />
Si ruby on rails vous fais peur, vous devriez vous attarder uniquement sur ruby pour acquérir une base potable du langage. C'est un langage très puissant qui à su tirer profit des qualités d'autre langage comme perl ou java. C'est rapide stable, simple avec un model de conception qui lui est propre et qui permet de faire du code même dans un gros projet avec une propreté qu'il est difficile d'égaler dans bon nombre de langages.<br />
<br />
Soutenir l'un ou l'autre... Je dirais qu'il faut rester très optimiste et espèrer que les deux langages se spécialisent plus dans la publication ou l'application. <br />
Ce qui est sur c'est que maintenant que j'utilise rails. Adieux php ideux ^^, aurevoir java et bonjour ruby! :) <br />
<br />
Un conseil, si vous ne savez pas le quel choisir: <br />
Faites des tout petit projet avec chaqu'un d'entre eux en créant les principals fonction dont vous pourriez avoir besoin. Ceci vous aideras à déterminer le quel est le plus adéquat à vote projet. (Ne naviguer pas trop longtemp entre les deux vous ne feriez que vous noyez dans les différentes qualités et de défauts de chaqu'un.)</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Olivier Mengué</span> le <span class="comment-date" property="schema:commentTime">27/11/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Pouquoi j'aime Django ? Pour son ORM !<br />
<br />
J'ai d'ailleurs fait ce week-end une préseantation sur celui-ci aux Journées Perl 2006. <br />
Les dispositives sont ici : <a href="http://o.mengue.free.fr/blog/2006/11/25/8-django-aux-journees-perl-2006" title="http://o.mengue.free.fr/blog/2006/11/25/8-django-aux-journees-perl-2006" rel="nofollow">o.mengue.free.fr/blog/200...</a><br />
<br />
Concernant le reste de Django, je ne le connais pas encore assez pour me prononcer.</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">David, biologeek</span> le <span class="comment-date" property="schema:commentTime">28/11/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>Wow, très bonnes présentations ! En plus aux journées Perl, il fallait oser ;-).<br />
<br />
N'hésite pas à t'inscrire à la mailing-list de django francophone : <a href="http://lists.afpy.org/cgi-bin/mailman/listinfo/django" title="http://lists.afpy.org/cgi-bin/mailman/listinfo/django" rel="nofollow">lists.afpy.org/cgi-bin/ma...</a></p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Philippe</span> le <span class="comment-date" property="schema:commentTime">29/11/2006</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>@Black pignouf : Il y a aussi celui la : <a href="http://blog.breek.fr/2006/10/23/le-comparatif-de-rails-django-et-cakephp" title="http://blog.breek.fr/2006/10/23/le-comparatif-de-rails-django-et-cakephp" rel="nofollow">blog.breek.fr/2006/10/23/...</a> qui me semble plutot objectif en la matière...</p>
    </div>
</div>
<div class="comment" typeof="schema:UserComments">
    <p class="comment-meta">
        <span class="comment-author" property="schema:creator">Samuel</span> le <span class="comment-date" property="schema:commentTime">26/01/2010</span> :
    </p>
    <div class="comment-content" property="schema:commentText">
        <p>J&#39;ai testé les deux frameworks et je pense que le choix porte plus aujourd&#39;hui sur l&#39;expérience du développeur en python ou ruby que sur les fonctionnalités des frameworks. Pour ma part j&#39;utilise principalement le Ruby on Rails car je le suis depuis ses débuts. Pour les non-initiés, je leur conseil de faire les deux Quick Start: </p>

<p><a href="http://guides.rubyonrails.org/getting_started.html">http://guides.rubyonrails.org/getting_started.html</a></p>

<p><a href="http://docs.djangoproject.com/en/dev/ref/contrib/comments/">http://docs.djangoproject.com/en/dev/ref/contrib/comments/</a> </p>
    </div>
</div>

    </div>
  </section>

    
    <footer>
      <nav>
        <p>
          <small>
            Je réponds quasiment toujours aux <a href="m&#x61;ilto:d&#x61;vid%40l&#x61;rlet&#46;fr" title="Envoyer un email">emails</a> (<a href="/david/signature/" title="Ma signature actuelle avec possibilité de chiffrement">signés</a>) et vous pouvez me rencontrer à Montréal. <span class="more-infos">N’hésitez pas à <a href="/david/log/" title="Être tenu informé des mises à jour">vous abonner</a> pour être tenu informé des publications récentes.</span>
          </small>
        </p>
      </nav>
    </footer>
    
  </div>
  
  <script src="/static/david/js/larlet-david-3ee43f.js" data-no-instant></script>
  
  <script data-no-instant>InstantClick.init()</script>
  
</body>
</html>