lesscode.org

Sam Newman has a fairly thorough comparison of Django and Rails over at magpiebrain.com. He compares the following traits of the frameworks: language, requirements and installation, deployment options, caching, project setup, adding models, interaction with the database, projects and applications, controllers and URLs, templating options, and administration / user management.

It’s a nice comparison, although the concluding section on choosing a framework seems to be getting some flak:

If you are developing a simple (in a domain model sense) application where you want to use Ajax to deliver a great UI, Rails is probably for you. If however you want to develop an entire site with different types of applications within it - then Django’s plugable applications and general approach might be what you’re after. Equally, the better user and administration side of Django favours portal style applications – this is something you’ll have to do yourself if you want to use Rails.

Rails is, of course, not limited to AJAX-heavy apps with simple domain models. I’m assuming Sam didn’t mean to give that impression but was just trying to wrap up a long article quickly. Perhaps he’ll clarify a bit.

Django committer, Jacob Kaplan-Moss, followed up with some thoughts on the post.

As a side note, I had planned to do a series around this but I promised Adrian and Jacob I’d hold off until Django was launched-launched, which I assumed meant 1.0 at the time but that seems a ways off now… I’m not sure Django can get any more launched at this point so I might have to revisit that promise as I’m anxious to get moving on this.

Once Django is launched-launched, I’ll be comparing various aspects of it with Ruby on Rails. I plan on diving deep into the two frameworks so instead of one large post, I’m going to make this a running series.

While I’m primarily a Python coder, I’ve been dabbling with Ruby for about a year and have a couple of apps under my belt with Rails. They are admittedly simple apps but what isn’t with Rails? I’ve also logged 70-80 hours against a Python clone of Rails’ excellent implementation of Active Record, which put me pretty deep into the internals of that piece.

I am not a Python zealot. And, to be honest, I’m floating between the two languages as my primary. What I’m trying to say is that my interest is in exploring these two frameworks objectively and extending my understanding of each, not advocating one over the other. I will include personal thoughts on design and may favor one or the other at this level but I will not be concluding the series with a recommendation for either because, frankly, I already know which I’d recommend at present and it has nothing to do with technical qualities (hint: it has everything to do with this).

That being said, I can recommend that if you are building systems that require the complexity of a full-stack web framework (i.e. PHP, CGI won’t cut it) and you are currently using something other than one of these two frameworks in any language (including Java and .NET) on any platform, that you move swiftly to adopt either if possible. If there is something barring you from making that switch, well, where’s your patch? Make it happen.

I realize that many in the Python community have already grown comfortable with an existing framework (or more likely, have written their own, like myself) and that’s fine as there are some competent frameworks out there. But it has become apparent that Django will be growing a large community of contributors and that’s something no current Python web framework of this kind can boast.

As I write this, there are 30 people idling in #django on irc.freenode.net on a Sunday morning, two days after the none-launch; there’s been 409 bookmarks on del.icio.us. Granted this is all very much driven by hype right now as there hasn’t been any real experience with the framework, excepting the maintainers, but the outlook for a large community to finally coalesce around a single set of tools and conventions is promising.

I also want to mention that I spent some time talking to the Django maintainers last night and they’ve convinced me that the Rails comparisons, while unavoidable, may be somewhat premature. Although Django has many of the same traits as Rails, it wasn’t built as an all out clone and may appeal to a slightly different set of requirements. Time will tell, of course, but as of right now the similarities are a huge part of what’s driving interest in Django and there’s a good reason for that - Rails got a ton right.

Still, “because it’s in Rails” is unlikely to be considered sufficient justification for Django feature requests. That’s a sure way of creating a Bride of Frankenstein framework and I’m pleased to see the maintainers have a strong sense of this. Django is likely to follow many of the same paths as Rails but that’s because they were both designed under real life circumstances with similarly excellent philosophy.

Before I wrap this up, I’d like to echo the sentiments of one Rails supporter in his comments on Django:

I hope Rails learns to play with Django and they’ll not smite each other (if not friends, don’t be enemies). The world is big enough. A combined message from different camps will be more resounding than any one camp trying to say he is the bestest - and coming off as naive or clueless.

Indeed.

(warning: stomach wrenching, KUM BAI AH, everyone-hold-hands type stuff imminent)

The Ruby, Python, Perl, and PHP communities must understand the immense opportunities that await them should they accept that they share much more in common than not and that a unified front would go a long way in tearing down the barriers that have kept these technologies out of the mainstream. The amount of positive impact these disruptive technologies could have on existing forms of business and social interaction in general are limited only by our ability to tell the story.

Feeds for the series:

• RSS2
• Atom 0.3