Django & Rails - another year another comparison

It is the time of the year where I start talking about Django and Ruby on Rails. Since my last two posts I received many questions about this topic and the old posts are still read frequently and quoted. So let me bring you up to date what changed, what improved since the last post and which framework is the best choice.

If you did not read my last two posts about this topic I suggest you read them now. I will make claims and statements in this post I already elaborated in them and without the context they can be quite controversial. To the disappointment of some of you: this is still not Django vs Rails - it is no discussion that will come to the conclusion that there is a holy grail of frameworks, totally destroying one of them with arguments why the other one is so superior.

While Django is slowly moving towards migrations being part of the core functionality Ruby on Rails just added support for real foreign keys support. Django 1.7, which will bring you the joy of migrations, is currently not marked as stable, but release candidate two makes a good impression and it should not take long till you can start new projects with it. I am even aware of people already using it in production and they seem to be quite happy.

There are new benchmarks provided by TechEmpowered but there are no real surprises nor did anything dramatically change. But since you do not choose Django or Rails for performance reasons you should not give too much about benchmarks anyway.

More and more features!

It slowly feels like comparing Django and Rails is getting harder and harder. Rails 4.2 beta 1 was just announced. Let us just look at one feature: Active Job. For those of you who do not use Rails - it is an abstraction layer for task queues and is compatible to the most popular ones. And you can just start with the inline runner and move to more advanced queuing systems. More concrete: If you want to send a mail in two hours you just do Notifier.welcome(User.first).deliver_later(in: 2.hour).

Rails is getting more and more features and moving more and more towards a "you get everything you need and build from there" framework while Django is still keeping everything the same and only doing small, incremental improvements - at least most of the time, migrations is an obvious counter example.

Paying the price

With Rails you pay the price for always getting new features. Things are constantly changing. Upgrading projects between releases is more work compared to Django. I still have Django projects that, accumulated, needed not more than an hour or two and have been running with 5 releases now. Upgrading Rails projects is always a bit more troublesome. But in defense it got a lot better than it was some years ago.

Language improvements

I pity everyone starting a project and having to choose a Python version. The arguments between the Python 2 and Python 3 fractions are still the same, the problems are not getting any better, libraries are still not all ported. Starting with Python 3 can become problematic if you need many third party libraries, starting with Python 2 could mean that you will be porting your project pretty soon.

Looking at the Ruby community it is a bit different. People are discussing advantages and problems of Ruby 2. But they are slowly and steadily moving towards it, Rails 5 will likely target Ruby 2.2. And this is understandable. The language is getting better, sane features are added and not everything blows up once you try to port something. Even if there are discussions the biggest part of the Ruby community seems to be in the same boat that migrating to Ruby 2 is a good idea - or I miss the parts that are die hard Ruby 1 fans revolting against 2. I will not rule out that possibility.

I still cannot stand Ruby but I have to admit I am also not a big fan of Python 3. If I had to choose today I would still go with Python 2 and keeping Python 3 compatibility in mind, but Ruby is getting better and better and more attractive.

One year later

I am keeping this post shorter than the other two for two reasons. First of all not many things really changed. Second, Django 1.7 is not released yet, Rails 4.2 is not released, Rails 5 will likely see a lot more awesome things than Ruby 2.2 support and is planned around spring or summer 2015. With this in mind it feels like next year will be a good time to take a fresh look at both of those frameworks and go back to the already discussed points.

From my todays perspective I would still stick to the arguments why you should choose one over another as last year and the year before. But I would likely add one additional thing to it: If you are trying to build a throw-away MVP to prove an idea or just get something out Rails could be the better choice. You have it easier to build an API. You get a better asset pipeline, and have it a bit easier to use a frontend JS framework. And now with Active Job Rails just ships another feature you will need at some point and, as starting point, is awesome to have as part of the framework instead of having to evaluate all the different options. Of course, this only applies if you can stand writing Ruby.

You can discuss this post on HackerNews.

>> posted on Aug. 31, 2014, midnight in backend, django, ruby-on-rails