Constant Contact Labs Developer Blog

• Rails vs Django: A Developer’s Comparison Posted Friday, February 12, 2010 Huan Lai 7 Comments

  

  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.

  Both 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?

   

  The opinions expressed here represent those of the author and not those of Constant Contact, Inc. Read Blog Terms

  Share

  | More

  Tags

  Open Source • Platforms • Python • Ruby • Web Development
  Next Post Previous Post

   

Comments (7) +comment on this post

 

• Sumit Chachra | 8:18 PM March 3, 2010

  If you’re a newbie developer then Rails wins ... anything more complex or if you like having more control or if you like having your app not randomly fail on you then go with Django!

  Nice real-world comparison!

• iJames | 5:11 PM March 18, 2010

  Thanks!
  I’ve been beating my head against one of your ties.  AJAX and Javascript.  I played with ROR first, and really liked how easy it was to swap out full screen refresh with a partial refresh using Rails partials.  Also I’m not sure how easy it is to determine PUT, GET, POST, UPDATE http requests on Django whereas on Rails it seems inherent.  I’m doing a Django project now and have learned about “inclusion tags” which might work for Ajax similarly.  I’m really hoping to have a nice framework for talking back and forth with the server and refreshing what needs to be refreshed easily.  I’ve been using tacnite for trying that out.  It’s a cool way of using a standard system for modifying parts of a DOM in a standardized way from the server.

  Thanks again!

• Frank | 2:00 PM April 28, 2010

  Very enlightening article. Since I started working on a project in Django, I’ve been considering RoR but knew (and like) python… At the time this pushed me to “just start” with Django. All in all, it appears to not matter. Your article has been the most enlightening between the two frameworks thus far. Thank you.

• Jens Backman | 4:47 AM May 9, 2010

  For Django database migrations, check out South.

  I’m not sure about the PUT/GET/POST/DELETE detection, but I guess you could do something like this:

  if request.method == ‘GET’:
    do_something()
  elif request.method == ‘POST’:
    do_something_else()

• GEoff | 1:54 AM June 7, 2010

  I feel that this article as well as the comments, fail to address one small facet of this discussion. Language choice. I personally prefer pythons syntax and simple power over Ruby. Ruby in my opinion is the lesser used language at the moment and I think this is for good reason. Python really is a very enjoyable language to work with. Im saying this having had very little experience with Ruby, but from the experience I have had..my choice is python / django over ruby / rails.

• Huan Lai | 9:25 AM June 7, 2010

  Thanks for the feedback, everyone.

  @Jens, I’ll look into South the next time I need to do some sort of migration. I read up on it a little bit based on your recommendation, and it seems to be pretty well supported.

  @GEoff That is actually the reason why I choose to work with python/django as well, language preference. That is pretty much the conclusion I made in my comparison as well - that both had their pros and cons, but both are very solid frameworks, and the final decision should be in language preference.

• SeanG | 2:31 PM August 5, 2010

  Thanks for the great real-life comparison. I’m kind of the opposite of you. I have experience with RoR and am trying out Django for the learning experience. I was curious if you could elaborate on (perhaps with an example) your comparison of Rails “magic” vs Django’s “convenience”... that distinction eludes me.

  From my Rails experience… here are my gripes about the RoR platform:

  - The Rails core development team makes no apologies when it comes to upgrades and releases. New rails versions almost invariably deprecate/break existing rails applications. If you don’t stay current with the latest release (taking every intermediate release as it’s available) then your application will rot away.

  - The Rails feature set and convention is driving madly to a RESTful framework. I’ve found the more they drive towards this, the more difficult it becomes to write “real world” applications. Simple tutorial applications that are just a catalog of database objects work wonderfully well in this framework but real world applications (in my experience) spend most of their time ignoring it.

  - While it adheres quite well to the ‘DRY’ principle, I wish it would consolidate the information more. In particular the Database ‘Model’ objects are spread quite thin. If I want to know what methods are available on a particular Model, I have to search through the Model (which has the custom methods) and the migrations (which have the object properties) to figure out what method I should be calling (or the physical DB schema when the migrations are too complicated).

Add your comment below