Django 1.3 vs Rails 3: A not so final showdown

"Some of you probably know that Python is currently at a bit of a crossroads. Python 2.x was the stable Python version for many years, but recently it was replaced by Python 3.x."<p>Python 3 has not "replaced" Python 2. The reality is quite a bit more nuanced than this, and it is hardly a bad thing that Django does not support Python 3 right now. To give this section the heading of "The great divide" is just a tiny bit hyperbolic.<p>From the top of the python.org page dedicated to the subject[1]:<p><i>Python 2.x is the status quo, Python 3.x is the shiny new thing</i><p>Also from that same page, here are some of the key things in Python 3 that are not in Python 2 yet:<p>* function annotations<p>* syntax for keyword-only arguments<p>* extended tuple unpacking<p>* non-local variable declarations<p>There is nothing in this list that a developer <i>must have</i> in order to develop their app, and there are no Python 3 exclusive projects that do not work with Python 2.<p>The fact that few major Python projects are currently ported to Python 3 is not evidence of some tremendous looming problem in the Python language. It is evidence that Python 3 is only, really, an evolutionary transition from Python 2 and that this transition has a long time horizon.<p>The move from Python 2 to Python 3 is nothing like the move from Ruby 1.8 to Ruby 1.9. There are no dramatic speed or stability improvements that make Python 3 something that is terrible to miss out on, and there is no rush to get projects ported to Python 3. It will happen when it happens.<p>[1] <a href="http://wiki.python.org/moin/Python2orPython3" rel="nofollow">http://wiki.python.org/moin/Python2orPython3</a>

I cringed when I saw him installing Django with yum. That's the surest way to end up with an ancient version.<p>You let the package manager manage whatever you are not very interested in (something you don't care with recent version you are running). I'd never let it manage something I can manage better.

Rails and Django are two web frameworks standing at the same place greeting people coming from opposite directions. They are vaguely familiar with what each other are doing, but for the most part are just trying to do what's best for their own users. They have way more in common than they have differences and I think each community could benefit from learning the other's workflow.<p>I think Rails is slightly more beginner friendly because of the conventions and magic but that becomes frustrating for more advanced developers. Rails is working on making themselves more customizable and Django is working on codifying standards. I'm pretty sure it's a meet-in-the-middle kind of thing.

<i>Official Docs - best official project documentation I’ve read. It’s actually so good, that I never (well - almost never) bothered to look for anything else. All my questions were answered by the official documentation.</i><p>I have a different opinion. The Django docs are good, but not great. Here's how I see them right now:<p><pre><code> - Combination of overview, how-to, and API reference. </code></pre> Instead, I'd like to see it split up like so:<p><pre><code> - Overview section. - How-To section. - API reference. </code></pre> The overview section should cover general concepts. "This is what a View is, how it relates to URLConf, etc...".<p>The how-to section should show you how to do certain things. "Here's example code of how you can configure settings.py, how to handle an HTTPRequest in a view function, etc...".<p>The API reference, just a list of Django objects (showing inheritance), their attributes, functions, and parameters. Excellent example: <a href="http://api.rubyonrails.org/" rel="nofollow">http://api.rubyonrails.org/</a> . Currently some of this is documented, but some of it is only visible in source code.<p>Right now, everything in the Django docs is semi-bunched together. This made it really hard for me to initially learn the API; I'd imagine others' have similar issues. Since then I've gotten use to the docs, but it's still frustrating at times.<p>I do like Django very very much, but this is one of its pain points for me. It goes away with experience, but for new users it likely poses a bit of a challenge.

One major area that the author did not cover: Modules.<p>The idea of 'Gems' in Rails(ruby) are exceptionally well engineered. Many powerful tools can be added by simply including a Gem.<p>On the Django side I have found the situation to be much worse. Many 'Apps' are hard to integrate and often it is easier to rewrite simple things than trying to customize them.<p><i>This is what caused me to switch to Rails after a year with Django</i>

Unfortunately, this article sounds very much like he was just introduced to Django. Great write-up overall, but it felt like lip service to Django with the real meat of the article is the RoR stuff.

Does anyone know what the "&#60;(" syntax does:<p><pre><code> bash &#60; &#60;(curl -s https://rvm.beginrescueend.com/install/rvm) </code></pre> I couldn't find documentation (hard to search for as you might imagine). Testing it out, basically that line downloads and executes the bash script stored at <a href="https://rvm.beginrescueend.com/install/rvm" rel="nofollow">https://rvm.beginrescueend.com/install/rvm</a> . Would like to understand how it works; is it related to the $(command) expansion construct? Why not use "curl -s <a href="http://files.redsymbol.net/foo/foo.sh" rel="nofollow">http://files.redsymbol.net/foo/foo.sh</a> | bash"?

He's not harsh on either, but I found it strange that having a pluggable admin is ok for Rails, but pluggable migrations like South was a big gripe.

Nice writeup. Thankfully doesn't have a clear bias like most of these type of comparisons! A powerful Django feature (the admin) is rebutted by citing plugins in Ruby; I think that the fact that it's part of Django really makes a difference, with the smallest Django test project you can enable the '/admin/' and use the models. Either way I agree with the conclusion: for webapps you really can't go wrong with either

Rails's community advantage over Django looks like something that is not likely to go away in any foreseeable future. Although Sinatra is getting popular, Pythonistas are split between Django (or the AppEngine variant), (Jinja), Tornado, Flask, Jekyll, Pylons, and so on.<p>With Ruby, Rails oftentimes seems like the obvious framework, whereas the same can't be said for Python and Django.<p>Getting into Django has been a bit of a pain in the ass for me - at least for being unable to work on it organically with some fellow students or co-workers - but is there any reason to believe that getting a big Python framework community similar to Rails's is a plausible prospect?

As far as documentation, I've found Django's approach to work better for me. It seems to be the norm in the Python community to document well and comprehensively. Python is the only computer language I've seen where, according to the creators, "Strunk and White apply" (<a href="http://www.python.org/dev/peps/pep-0008/" rel="nofollow">http://www.python.org/dev/peps/pep-0008/</a>) . With Rails, the community approach toward documentation too often seems geared toward beginners. Many gems provide a "copy this, generate these files, and type that" tutorial or a screencast. I'm reminded of the code-generating wizards you'd see in Microsoft Visual Studio back in the day. Often there's no documentation beyond an initial tutorial. When I tried Rails last year I found myself spending the majority of my time Googling and sifting through blog posts of varying age and quality in an often futile attempt to find what I needed, whereas with Django the majority of my time is spent actually coding, and if I really can't find something in the documentation, Django's code is so readable it's often easy to open up the source and discover what it's doing.

I recently came across the Play Framework for Java. Though I haven't started using it in a real project yet, it does seem very interesting and rails/django-like with very similar tools and workflow, though for Java.<p>So for folks who are trying to decide between Rails and Django, Or come from Java background, that is another framework to look at.

To me, this choice comes down to what type of site I am building.<p>For an API: Sinatra. A CMS: Django. A sprawling web app: Rails.<p>Each frameworks was built to address a very specific set of problems.

I could have bet 100$ that RoR would have been chosen simply by reading the first paragraph: "I've already used Ruby a few years ago but I'm new to Python". What else do you want?<p>On a side note, Django is far from being "minimalist"; <a href="http://flask.pocoo.org/" rel="nofollow">http://flask.pocoo.org/</a> is minimalist, not django. I'll agree that Django is also less "Convention over Configuration" than Ruby.. for instance, it's a bit hard to chose where to put helper functinos in Django, whereas Rails put a helper file for you, etc.

I can't speak for Django but I've just begun learning Rails as my first web framework and its been a pleasure to use. It's DSL is incredibly expressive and offers great power with little effort. Aside from the expressiveness the TDD integration and conventional project structure are big wins too.

I've picked Django because it can be run with pypy (jit python) and makes it very fast. I prefer minimizing server costs.

I've been working on a new site in Pyramid (the successor to Pylons), and I have to say so far it's been an impressive experience. They took a bit of a different philosophy than Django and Rails. In those 2, you can customize some things, but there are also default options, and particularly things like the ORM are built into the framework. Pyramid behaves more like an application widget where the pieces of a modern web app (ORM, security, templating, URL routing) can be fit into its slots.<p>I did enjoy the article's touching on Django. It looks like it has gotten less monolithic than in prior versions. As I recall several years ago, Django really was like the Rails of Python, with tons of default options but some difficulties in customization. It looks like they have moved away from that somewhat.

I'm looking forward to learning RoR, even more thanks to this article. But please don't get the impression that only Rails works well with jQuery and SASS. I've been using them with django as well. They're not baked into django, but nothing prevents you from using them effectively.

What about optimizing your app later? I've rolled out a number of rails apps, and I now feel that the rapid prototyping it provides is actually a form of technical debt. The execution speed and memory footprint mean you will have to scale harder, faster. I would like to remove framework components and middleware that I am not actually using, and transition cleanly from a rapid rollout to an optimized final product. But even in rails 3 I haven't seen good evidence that it's possible to do this, without being hackish. How do Django and other frameworks handle this?<p>Another way of saying it is I would like a framework that is "additive," where you start with a very lightweight core and then add components as you need them.

A word of caution... Django should always be installed from Pip. Avoid easy_install, apt and yum.

I think seeing the huge project structure after initializing a Rails app vs. a Django app is what keeps me away from Rails. I prefer a minimal starting base that lets me immediately make decisions about my app. I do need to give rails another chance though.

I think he got it totally wrong with his unscientific estimation of rails and django with google trends. What has google trends to say here? Dislike.

I switched to django from rails 2 years ago because I grew tired of getting burned by black magic. Back then, rails had the reputation of being amazing at building specific types of web applications but going outside that box only resulted in pain. I haven't heard that recently. Has rails gotten better in that regard? I know they've gone through at least 2 major revisions since I knew how to use it.