Django vs. Rails

One of our first tasks getting started building FeedMagnet was to pick a development framework. I built the original prototype of FeedMagnet in PHP because it was the language I knew. When I decided to hire a developer and build out a production version of FeedMagnet, I knew I didn't want to stick with PHP for a number of reasons - the main one being that I wanted to develop in a top-notch framework and I didn't feel like CakePHP and CodeIgniter were quite there yet. I've had a number of people ask me how I made the ultimate decision to go with Django, so I decided to write this post to answer that question and hopefully help others who end up in my shoes to make the right decision.

To be honest, like many developers, I was drawn to the allure of Rails. The code is clean - none of that funky PHP $punctuation; - and the framework is fun to work in. The PHP frameworks I had used seemed to be cheap knock-offs of Rails (CakePHP is almost a direct port of Rails for PHP) and I wanted to work with the original instead of an imitation. So I started out with a bias toward Rails.

Even so, once I started really doing my homework I kept coming across Django as an viable alternative. Unlike the PHP frameworks I had played with in the past, Django was written in Python - which is actually faster than Ruby and in many ways has cleaner syntax as well. Plus, Django is not a knock-off of Rails. It approaches the problem of building a web framework in a unique way and doesn't even attempt to share terminology with Rails for things as basic as model-view-controller (Django uses the terms model-template-view instead).

I came to the point where I needed to make a decision between Rails and Django. I had narrowed it down to these two frameworks, but I still had a hard time making the decision. I read a bunch of articles (see links below) and talked to a lot of developers on both sides to get their perspective. The primary areas I was trying to evaluate were:

• Availability of coders
• Ease of learning
• Innovation - adoption of new tech
• Speed/performance
• Development philosophy

Availability of coders

This one is probably a toss up. There are many more Rails developers out there, but there are also a lot of hacks in the community. There are probably close to as many good Django developers as there are good Rails developers - you just don't have to hunt through the bad ones as much to find them.

I also went into this with the assumption that I would want to be able to hire coders who already knew the framework FeedMagnet was built in. So if we chose Rails, I would want to hire coders in the future who had a lot of experience with Rails. I ended up deciding that a good coder can learn any framework. Someone who has experience in Rails, or even CodeIgniter, should be able to pick up Django without any trouble. And if a coder already has good theory and coding practices, those should transfer to whatever language and framework they learn next.

Ease of learning

Since I was open to hiring developers in the future who would need to pick up the chosen framework, it was important to me that it be easy to learn. Plus, even though I'm not doing the majority of the coding, I wanted to learn the new framework as well - so this one was immediately relevant to me.

The documentation for Django is excellent. It used to be significantly better than that of Rails, but Rails has made a lot of strides toward improving their docs and the new guides are actually really good. So another toss up.

Innovation - adoption of new tech

The Rails community tends to gravitate toward shiny new objects a little more than the Django community. Textile, Haml, Sass, and a number of other tools grew out of the Rails community. Many of these innovations are available to everyone though - Textile, Haml, and Sass certainly are (in fact, we're using Sass for all of our CSS with FeedMagnet). So the Rails community may be a little more innovation-oriented - which is a plus for them. The Django community tends to be a bit more cautious, showing preference toward things that are proven - which can also be a good thing. And the Django guys are quick to jump on new technology when it makes sense. Django's support for CouchDB (another technology we are using with FeedMagnet) is a good example of this. I'd give this one to Rails by a slim margin.

Speed/performance

This one is a win for Django. The framework itself is probably not any faster than Rails, but Python is quite a bit faster than Ruby. With all of the effort being put into improving Ruby, the the playing field here will likely be leveled in the future, but for now Python has the win. One thing to consider here is that for most web sites and apps, the performance difference between Ruby and Python will be negligible. It is more important to have a framework that saves time and effort in delivering new features and maintaining code - which thankfully, both frameworks provide.

Development philosophy

It was the philosophical differences between Django and Rails that ended up shifting my bias toward Django. Rails tends to have a focus on "magic" - having the framework do lots of complicated things in the background, but making it all seem simple and magical to the developer. Django tends to be more "pragmatic" - having the framework do just as much heavy lifting for you, but with the emphasis being on it saving you from having to do those things. It is a minor difference, but Django developers seem to know more about what the framework is doing and appreciate it for saving them time, whereas Rails developers tend to not want to know everything the framework is doing, but rather be impressed by how it just magically works.

You see Rails developers make comments like "isn't this line of code clever?" - where a Django guy would say "Look how simple my code ends up being and how much time I am saving." I know. Very subtle difference there. Another way to put it is that most Rails guys want to write code that is "bad ass" whereas Django guys tend to be more about getting the job done as quickly as possible while keeping the code well organized and maintainable. I'm not arguing that Rails code is not just as time-saving, organized, or maintainable - the difference is that Rails guys get a kick out of being rock stars while Django guys are content to just get the work done.

Making the right decision

Django and Rails are both great. There isn't really a clear winner between the two frameworks, and if you've already narrowed it down to these two tools, you can't really make a bad decision. In my opinion, it is more important to get the right team on board so that you get the most out of the tools.

In my case, I made the decision to hire Luke and let him make the decision between frameworks. He had the advantage of having done projects in PHP, Rails and Django in the past, but his preference is for Django because he tends to be more of a "get it done" coder than a Rails rock star.

Plus, the built in admin app in Django is amazing. It has already saved us quite a bit of time.

- Jason

A few additional references

• CakePHP vs. Django vs. Rails vs. Who Cares - Make a Decision
• A Rails vs. Django Comparison
• Rails Envy's Ruby on Rails VS Django video (funny - although I think they got the personalities backwards)