My experience with Django and Rails

I’ve had the opportunity to work on both Django and Rails frameworks recently as part of one project.  The core application for the church administrative tools that I am working on is written in Rails, while the church guest follow-up application that I am responsible for is written in Django.  Why two separate stacks?  GuestView began its life independently from Gospel Software, and I chose Django there because of my familiarity with Python.  Three developers are sharing responsibility for the core of Gospel Software, however, and we chose Rails as the most reasonable lingua franca.

What follows are my personal opinions and observations.  These are mostly aesthetic or other value judgments, and I offer them simply for your consideration.


I’ve used the Python programming language for a number of years and like it a lot.  I particularly enjoy its functional aspects, although lately I’ve become more of a fan of using list comprehensions and generator expressions wherever possible compared to map() and filter() with lambdas.  Compared to Python, Ruby has much more powerful functional capabilities, although some things don’t feel natural to me (Ruby’s design choice to not require parentheses to denote function invocation means that you must use .call to call a lambda, which feels clunky).  There are also some cases in Ruby where choosing one of several alternative forms of an expression can have a significant impact on your performance.  Lambdas seem particularly costly in Ruby as of version 1.8.

Overall I think the languages are fairly on par.  Right now I prefer Python for aesthetic rather than technical reasons.  As I grow in familiarity with Ruby, and as it matures and its performance improves I think I may eventually grow to prefer it.

Object-Relational Mapping (ORM)

The Django ORM is very powerful and you can express complicated queries very efficiently using it.  Django queries are not executed until they are actually used, so you can construct your queries piecemeal, which helps in writing readable code.  Django also allows you some flexibility with adding custom SQL to your queries, but for anything complicated I’ve found that I have to break down and write my own SQL.

Rails 2.1 introduced the ActiveRecord named_scope functionality.  Prior to this Rails was significantly lacking compared to Django’s expressive power for query construction, but named_scope pretty much evens the playing field.  And for complicated queries, which you will surely face in any real-world project as you seek to tweak performance, ActiveRecord gives you a degree of control over your SQL that really puts Django to shame.

Both Django and Rails seem to have adequate support for PostgreSQL, my database of choice.


Django lets you express your URLs using regular expressions; Rails accomplishes this using routes.   I personally prefer Django’s method, but both work well enough.


While Rails’ Embedded Ruby allows you to include arbitrary code in your templates, Django’s template engine is much more spartan.  It provides ways of getting at variables passed to the template, including objects, dictionaries, lists, and even methods.  And it has some simle control structures, but not covering the full expressive power of Python.  I yearned for a more powerful template language in Django at first.  But I found over time that the discipline of  a simple template language was helpful to me, forcing me to move any complicated behaviors to the controller (or “view” as Django calls it) which was in most cases the right thing to do anyway.

There are still some areas where I think the Django template language is lacking.  However, there is an open-source alternative to the Django template engine that is similar but sufficiently more powerful to meet my needs: Jinja2.

For me it is a toss-up between Embedded Ruby and Jinja2.


I suspect it’s common knowledge that Rails has a little ways to go in performance.  For our own purposes, I didn’t find too much difference in time measurements between Django and Rails.  However, Rails clearly has a much larger memory footprint than Django.

I was surprised to learn that even with a FastCGI or WSGI model, Django still opens and closes a database connection for each request.  While there may be technical reasons that the Django architecture requires this, it was still a surprise to me.  Django performance still seems on par with Rails in spite of this.  Interestingly, having Django use pgpool to connect to PostgreSQL didn’t improve my performance at all, perhaps because my application and database are currently located on the same host.


Both Django and Rails allow you to run a REPL session for your application.  The Rails script/console command beats out Django hands-down, because Rails’ internal magic automatically imports pretty much everything you need.  In Django you still need to import any models or framework modules before you can use them.


The Rails built-in log is enabled out of the box and is very handy.  Django provides logging functionality but you have to do a little extra work to enable it.  Rails wins out on logging.  Django is better at in-browser rendering of exception tracebacks.  Overall the handiness its logging means a slight win for Rails here for me.

Admin Application

Django’s admin application is truly its crown jewel.  If you need a private admin interface to your web application, Django will give you a very attractive and powerful interface almost entirely for free.  I’m not aware of any equivalent for Rails that even comes close to this.


I’ve deployed Django using FastCGI and Rails using Mongrel.  Right now I am using Nginx to proxy to Mongrel, and to connect directly to the Django FastCGI instance.  Neither Django nor Rails seems to have a unique advantage or disadvantage in deployment.


I’ve spent more cumulative time with Django than with Rails, so I feel subjectively more at home with Django.  If I were going to write a small toy project, I’d choose Django mainly for ease and efficiency.  In fact, I took this route for the meal and potluck scheduler application that I recently wrote for Google App Engine.  GAE has many similarities with Django, and even allows you to run much of the Django stack on it.

However, for larger projects my current framework of choice is Rails.  With the named_scope functionality in Rails 2.1, ActiveRecord is finally on par with Django’s ORM.   And for any complicated queries ActiveRecord is superior to Django’s ORM.  While Django’s admin application is handy, I don’t make much use of it.  And while Rails falls slightly behind in performance and storage characteristics, I believe that Ruby and Rails will both continue to improve in this regard.

9 thoughts on “My experience with Django and Rails

  1. Coming from .NET, Rails was bliss. Ruby is very pretty and has some very nice features, but 99% of the sites I build need an admin, and I hate writing admins.

    First of all, I think both frameworks are good. However, what I discovered through my experience with both frameworks over two years, is that what Rails had in hype, Django had in substance.

    I found that I could accomplish tasks faster, with more portability in Django than I could in Rails. Django’s admin gets me 99% of the way there with most projects, and that single app module alone has saved me months of development time and greatly streamlined the process of administrating data and permissions.

    Django’s application structure and url patterns are highly modular to begin with. I can pull in apps as an svn:external, add the app to my installed applications, add the url patterns (2 lines of code total), sync my db or run the South migrations, and I’m up and running. Yes, you can write plugins in Rails, but it’s not the same.

    I feel that Django’s ORM is just as or more powerful than ActiveRecord, with very clean syntax. Q objects make it very simple to create highly complex queries.

    Django’s template system, while spartan in appearance, is much better in my opinion than allowing the embedding of pure Python or Ruby code in templates. You’re forced to encapsulate, and it makes for highly portable code. If you’re a Django developer and haven’t looked at writing template tags or inclusion tags, do so today.

    Django’s popularity is reaching a tipping point, and I’m getting more and more calls from recruiters looking for Python/Django people.

    In 13 years as a professional developer, it’s the most well-conceived framework I’ve used. It put the fun back in development for me, and saves me a lot of time. I’ll get on my soapbox for Django any day against Rails, .NET or PHP.

    My $0.02.

  2. I was only a hobbyist developer (and student) when I wanted to start writing web apps. I had heard of this great thing called Ruby on Rails and so I checked out the short introduction tutorial video. It seemed ok.

    Then one of my friends said “Why are you using Rails, Django is much nicer”. I had never heard of Django, but had a look and it clicked. The whole development workflow made perfect sense. I could visualise the whole project in its separate parts.

    I had not done a huge amount of development before, only a few High School projects in .NET, and some attempted iPhone apps, but from a beginners perspective, knowing nothing about the languages or the frameworks, Django made so much more sense and felt like ‘the right way’ to do it.

    I would highly recommend it for any web development. I now have a part time job as a Django developer!

  3. For me the tipping point was Python. I have looked at the Ruby syntax and its really not “obvious” in the way that Python is. I came to Django from a framework called Cocoon – and while they share some concepts, the sheer power and flexibility of Django (“Django is just Python”) blew me away!

    1. I must second the “Django is just Python” quote. It really is so flexible. Also, I agree with the point about the syntax. When I started learning, that didn’t really bother me, but now when I look at Ruby it looks very ‘confused’, like the language doesn’t know what it is doing. Python on the other hand is very clear.

  4. “Now when I look at Ruby it looks very ‘confused’, like the language doesn’t know what it is doing.”

    I am not sure how you can come to this conclusion.

    The code I write in ruby since 6 years is very terse and very clear to me. Neatly arranged OOP too, with happy objects floating about.

    I really fail to see how Ruby is not very clear. What is unclear about Ruby?

    The whole Rails code is fairly trivial as well. I don’t get your complaint Dan Palmer.

    – shev

    1. personally find both ruby and python code fairly ugly to read. particularly ruby, i just hate the character symbol choices. sounds stupid, but it just irks me

  5. I’m not sure what the substance of this comparison is. Three points;

    Django and Rails are both high level frameworks written in easy-to-learn scripting languages. We are comparing ‘brand a’ electric screwdriver to ‘brand b’ electric screwdriver.

    Stop comparing PHP/.NET to Rails/Djanog. Comparing a _language_ to a _framework-written-in-a-language_ does not compute. It’s like comparing a Twix-brand candy bar to a alternative confection process. One is genius and requires engineers – the other requires a hungry simpleton capable of removing a wrapper.

    Use whatever works for you. The time spent reading an arbitrary viewpoint(yes, like this one), could be spent learning a countless number of skill sets to accomplish the same task.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s