Django vs Ruby on Rails


a year ago

Choosing the right framework in the developers’ world sometimes is similar to choosing between Ford Mustang and Chevrolet Camaro in the automotive world. The same purpose, parity of characteristics, lots of features, etc. This list tends to be endless, but, let’s make things a bit clearer by comparing these frameworks step by step.


Django was born in a newsroom to deal with strict time-limits. It had to exclude a lot of routine activities during the development process. The Django project is represented as an app. You can combine different applications to build a more scalable and functional system with separate application modules that will not interfere with each other. The key Django’s philosophy implies that the final code is pretty verbose so it can be read by the developer who has no working experience with a particular product.

Websites that are based on Django: Bitbucket, Disqus, Instagram, Mahalo, Mozilla, NASA, National Geographic, Pinterest, Rdio, Reddit Gifts, The Guardian, Washington Post.

As the main platform, Django is often used in the science world.

Ruby On rails

RoR has the "coding by convention” paradigm in its root (core) providing developers with simplicity and flexibility without getting them overwhelmed with many intermediate decisions to be made. Rails framework is strong in “magic”: that’s the way developers call its automation. With RoR, you can only specify some “unusual” aspects of your application and the rest will be done automatically.

Websites on RoR: Basecamp, Bloomberg, GitHub, Heroku, Hulu, Scribd, Shopify, SlideShare, SoundCloud, Twitter, Zendesk.

As the main platform, RoR shows its strengths in startups.

Basic tech comparison


In Django, all models representations are declared via the However, in order to handle attributes' behavior, you have to create two additional attributes and parameters. RoR handles these aspects on its own.

The Django model file can show you model fields type and a database structure for an application, whereas in RoR the schema.rb provides info about field types and a database structure while model files keep models themselves. When you initiate a migration, RoR takes care of any updates to this file.

Both RoR and Django imply implicit methods that allow a developer to find a database record by a model attribute. find_by for RoR and filter() for Django.


RoR supports migrations out-of-the-box via the Rails generator. Before the version 1.7, Django used the South third-party library for these operations. As of the version 1.7, the South library is not used anymore, Django itself has this functionality.


Both frameworks support object relational mapping so SQL queries are created quite easily.


The difference here is slight. Model-View-Template in Django is an alternative to Model-View-Controller in RoR. The Django view performs the role of the MVC controller as well as the template of Django is the MVC view. Similar principles in regard to MVC resolve into common functionalities of these two frameworks.


RoR has an interesting feature that is a downside from the other point of view: it uses the ERB Templating which allows generating an arbitrary text from templates themselves.


RoR has powerful built-in assets that allow performing different optimizations with CSS and JavaScript files.

In Django, you should take care of this on your own. However, if you want to achieve something similar to the Rails assets, you can install the Django-pipeline or any other third-party application out of available ones, that are numerous.


RoR makes things simple thanks to coding by convention, automatically routing GET requests to controllers, and setting all general routes. Django, on the other hand, uses the power of regular expressions (it provides developers with a built-in simple validation): but you still can do anything with routes and routing rules – they should be declared by hand.


At this point, Django and RoR are very similar, but RoR gets additional points due to automation. There are also additional applications that transform testing to joy.


Django uses a configurable user model of a user authentication, whereas RoR doesn't have any built-in user authentication at all.


  • Open-sourced
  • Both are MVC and follow DRY principle
  • Automatic queries
  • Easy routing system
  • Powerful template system with a lot of filters and predefined functions


  • Django is written in Python and Rails in Ruby.
  • RoR doesn’t provide you with any authentication services out-of-the-box, you should use some of the third-party solutions.
  • RoR seems to have a bigger and less fractured community and more career opportunities for developers. It is also a rookie-friendlier which allows more people to be involved in the development process.
  • Django has a stronger backward compatibility due to less frequent changes to its API.


It may seem that RoR has a slight advantage, but that's not quite so. When writing code, automation is very helpful, but it’s not always necessary – some fragments can be added by hand much faster (instead of editing a bunch of default values) and you will be absolutely sure that these fragments will work in any situations. And if you plan to refactor or scale, more verbose and readable code will make it simple for developers to control each step and eliminate possible errors.

So, Django or Rails? This is your own choice, according to your experience, professional skills, and goals.

Django is an excellent choice for those who are looking for more customization, tech-maniacs who like to play with code spending much time “under the hood”. It has a wider application in data science and business, which resulted in many professional applications. If you care about backward compatibility, Django is also better than RoR here.

RoR concentrates on the faster launching of your Web applications getting you more familiar with framework concepts and allowing you to implement some complex features faster thanks to automation and shortcuts.

Also, you can see our white paper:

Get our

White Paper