Background

As a framework Rails has been around for little over a year, whereas as a framework in its own right django has only been public for around two months.

Actually, Django’s been in use internally for over two years, although we only got the buy-in from management to release it as open-source two months ago. So Django’s actually very stable and mature; a 1.0 release is more a matter of responding to community needs than fixing bugs.

Languages

On the face of it, the biggest difference between the two has been the choice of development language.

This is true, and I’m not going to even try to get into a Python versus Ruby argument. However, one of the things that draws me to Python is the great size of the “ecosystem” – there are a great number of awesome Python libraries that Django can leverage. A great example is the Django community page; the code that drives the aggregator is extremely simple thanks to Mark Pilgrim’s wonderful Universal Feed Parser. Being able to draw on all these wonderful Python libraries makes my job much easier.

Testing

My feeling is many people new to testing are more likely to do it with Rails because it’s built right in and it’s well documented.

A very good point; Django’s got a testing framework for Django itself, but a solid framework for tying tests into your models would be extremely useful.

Models

The only minor annoyance is that there is no equivalent of a model-specific SQL refresh - something that could drop a specific model’s tables and regenerate the needed SQL automatically. Instead you have to have the admin script dump out the SQL to the command prompt and run it in yourself.

I actually see this as a feature, not a bug. Dropping tables and regenerating the schema is one of those things that can result is horrible data loss if you’re not careful (yes, I do speak from past mistakes). I really like being able to get a look at any potentially destructive operation before it’s performed.

Django does seem to offer the ability to reverse-engineer models from an existing schema, although I don’t have information as to how sophisticated this is (for example to what extent it can determine inter-model relationships).

Right now it’s not as sophisticated as we’d like; it will neatly figure out the Django equivalents for each field type, and it will indeed follow inter-model relationships (although with many-to-many relationships it will explicitly create the join model, which is probably not what you want). However, The generated models do take a bit of massaging by hand to get working, but it’s a feature that’s in active development and should be nearly automatic by the time we’re done with it.

Again, thanks for the great article, Sam!