Rails vs Django: A Developer’s Comparison

As you might know from reading some of my previous blog posts, I’ve been working with Python and Django pretty extensively over the last year, mainly for rapid prototyping and developing relatively simple web applications (including a Facebook App). During Cool Stuff Week I decided to try using Ruby on Rails (RoR) as the base framework, as a learning experience more than for any other reason. So what’s the difference between these two popular dynamically typed frameworks?

Note: I am first and foremost a backend developer and have bias as such.

Rails vs DjangoBoth Rails and Django are both open source web application frameworks intended for rapid development that follow some form of the model-view-controller architectural pattern. RoR, developed by David Heinermeier Hansson from his work on Basecamp, a project management tool by 37signals, is the defacto standard web programming framework for Ruby. Django, developed by The World Company to manage several news-oriented sites, is one of the most popular web programming frameworks for Python.

Both Rails and Django use HTML templates extensively. The key difference lies in the fact that Rails templates use inline Ruby code fragments whereas Django uses a specific templating tag language. Rails allows for more complex functionality if need be, but Django is simple enough that web designers with minimal programming knowledge can build templates. Although Django makes it easy to develop custom tags that can be used in the same way as native tags. I’ll have to pick Django on this front.

Along the same theme of presentation layer, Rails and Django are very different in their views towards JavaScript and AJAX. Rails comes shipped with the Prototype JavaScript framework and the Scriptaculous JavaScript controls and visual effects library. Because of this standardization, Rails also ships with a number of ways to take care of the dirty work when it comes to sending and responding to AJAX requests. Django on the other hand comes only with a JSON module, leaving any and all JavaScript decisions and development to the developer. While I have not yet had to write any applications that utilizes AJAX, I can definitely see why the built in support for it by Rails can be very useful. At the same time, there is also an advantage of not having any sort of JavaScript decisions made for you in Django. For the Facebook Join My Mailing List project, I noticed some oddities with Facebook’s FBJS. I can only imagine how Rails’ JavaScript integration behaves in such an environment. As I haven’t had enough time playing with Rails, I can’t really judge the pros and cons and will leave this a tie.

Both Rails and Django use object relational mapping to link the application to the underlying database, but Rails and Django have very different ways in which model objects are defined. In Rails, model attributes are not declared in the class definition. Instead, Rails can retrieve all of this information from the database based on the class name (by convention, database tables corresponding to model classes have the same name, but there is a way for the developer to write extra code to deviate from this convention). In Django, the developer is required to explicitly specify each attribute of every class. From there, there are standard tools for creating a database schema from the model definitions. I haven’t tried to change the database schema for my Rails project, but I’ve read that it has a migrations mechanism for easily doing changing the database schema while preserving and appropriately modifying the existing data. I did have to do this in the past for Django projects and it is rather painful. I’ll have to pick Rails on this front.

Along the same theme of managing the underlying database, Rails and Django have different ideologies for admin pages. Django has a built in system for automatically generating admin pages for model objects with ways to customize the presentation. Rails does not come shipped with an automated way to generate admin pages, but there are plenty of 3rd party plug-ins out there to do the same thing. As I haven’t actually tried out any of the plug-ins for Rails, I can’t really judge how well they work, but the convenience of having a built in system that works quite well makes me choose Django as the winner on this front.

Both Rails and Django allow for the use of regular expressions to customize the mapping of URLs to controller actions. Both are flexible enough to allow you to create pretty much any mapping scheme you wish. By default, Rails also does automatic URL mapping based on the class and function names within controllers. This is further evidence of their Convention over Customization philosophy. I’ll have to pick Rails on this front.

From reading up on both frameworks, there is a subtle, but noticeable, difference between their philosophies. Rails focuses on having the framework do stuff in the background for the developer, making it all seem simple and easy. The Django framework does just as much heavy lifting for you, but emphasizes on the fact that it is saving you from having to do these things yourself. These two ideas seem to be the same, but the Rails point of view has more of a “magic” visage whereas Django has more of a convenience one. I personally prefer Django’s approach to this, but I’m sure there are plenty of people out there who would disagree.

At the end of the day, both frameworks are great. There really isn’t a clear winner and there really isn’t much incentive to migrate in either direction if you’ve already gotten entrenched with either camp. But if you’re currently out shopping for a framework to use for a new project, the biggest factor in determining which to use is your preference of Python vs Ruby. I’m already in the Django camp and don’t see any reason to switch over, but you can’t really make a bad decision with either of these frameworks. I’m sure there are plenty of people out there with strong views in either direction, tell me how you feel about these two. I’m going to try to spend a little more time with Rails to give it a better analysis; anyone with more experience with Rails than me (not really all that hard) want to comment?

Continue the conversation by sharing your comments here on the blog and by following us on Twitter @CTCT_API

Leave a Comment