Language knowledge (Python v. Ruby)
Availability of developers
Amount of third party code specific to your needs
Especially when starting from scratch, learning RoR is kind of like "ooh, shiny, magic, wow!" and learning Django is like "so you do this, which does (this and this and this behind the scenes), then do this..". I love magic as much as the next gal, but not being able to fully grok RoR from the start was partly why I chose Django as well.
If you like the meta-magic of Ruby, you'll probably like Rails. If you like the straightforward nature of Python, you'll probably like Django more.
This basically just says Rails has a better user interface than Django (not necessarily something I agree with).
Django makes you feel like a power user because it forces you to learn more in order to use it?
I find this this statement hypocritical.
Sorry, what? How could one possibly know there are more hacks in the Rails community than in the Django community?
I'm all for comparing the merits of various languages and frameworks, but this article is more about gut feelings than facts.
He wanted to feel more like a hacker, and rails hid (of course by hide he means publishing the source code) too much of it's magic.
In fact, I think publishing an article on Rails v.s. Django and posting it to Hacker News stinks of SEO.
1. Deployment and scaling is a lot easier on Rails b/c of several dedicated hosting providers that specialize in Rails. Engine Yard is the one we use, it makes scaling extremely easy. I'm not sure if Django has similar companies.
2. Rails-specific SAAS are super awesome. Newrelic/Hoptoad, etc. They make tracking your software and errors a lot easier than the less supported Django.
3. Speed is a non-issue; scaling is 100% about making the DB scale. Furthermore Ruby 1.9 is going to be faster than Python 2.
4. Training a developer to learn Django is not as trivial as you think. There are a lot of "tricks" in these frameworks that make working in them very fast, these take time and experience to pick up.
I can't really agree with this being a good thing. The MVC pattern has been around much longer than Django or Rails, thus Rails is using an existing nomenclature where Django is not.
Rather than MVC (Models, View, Controller), Django uses MTV - Models, Templates and Views.
The M in both is pretty similar, and is typically an object representation of what is in the database.
Django differs from the more established MVC model. In Django-speak a view is a function that takes optional arguments, processes data on the model, and (typically) outsets key/value pairs of object. They key/value pairs get fed into the template. E.g. if you did had a URL /sales/by_country, then a view would be executed that would do a query that returned the sales by country in a pure python data-type (e.g. a list). All the presentation code, would be be done in a template.
In MVC, you have controllers that were the 'business logic' and views that were the 'presentation code'.
MVC is arguably more pure from a design perspective, MTV arguably fits more naturally with the way the web works.
This 'snakes and rubies' video starring DHH and the Django team is a good session that explores it in more detail. (http://video.google.com/videoplay?docid=2939556954580527226#)
1. Django Templates correspond to Rails Views (they both define how data is presented to the client). The biggest difference is that it's easier to include business logic in Rails Views because the Erb template language is as expressive as Ruby itself, while the Django template language is deliberately restrictive.
2. Django Views correspond to Rails Controllers (they both process requests). The biggest difference is that data is passed explicitely from a Django View to its Template, while data is passed implicitely from a Rails Controller to its View.
I toyed with Django for a while before I moved to Rails. The main force driving me to Django first was that I already knew Python, whereas I'd never really used Ruby. I chose Rails over Django because of the magic. It seemed like I had to learn a lot more up front to get a web app working in Django, where I could get things working first in Rails while learning what the framework is doing over time.
I'm not trying to stand on a soap box one way or the other here. Maybe a less combative post title could have helped tone down the commentary. The reason I wrote the post was that I had found myself explaining my decision to a handful of people and I thought maybe more folks could benefit from the "research" (intentionally in quotes to designate that is was not "real" research) that I did while getting ready to make the decision.
If you want to fire arrows back and forth at each other, feel free. I'll probably not get too involved though since I don't always find those discussions productive.
- Jason (author of the original post)