Ruby on Rails vs Django

Compare of features and capabilities of two popular frameworks
12 July 2017   1520
Ruby on Rails

Framework written in the Ruby programming language

Comparing frameworks is a hard task. Each platform is developed to solve specific problems and has its advantages and disadvantages. Therefore, the framework, unsuitable for some projects and programmers, can perfectly prove for others.

To develop web applications, many auxiliary tools have been created in different languages. The two most popular platforms are Rails, which uses Ruby, and Django, written in Python. Let's figure out what are the differences between them and for what tasks they are intended.

Used model

Both frameworks implement development using the MVC model. As follows from the deciphering of the abbreviation, this template includes three main blocks:

  1. Model. The main project databases are: users, posts, comments and the like.
  2. Performance. Visual display of information from the model.
  3. Controller. Intermediate link between the model and the view, which processes the requests of users and demonstrates the result of their actions.

There is no significant difference in the representation of these blocks in the frameworks. In Django, some templates are called differently, but they use same principles as Rails do.

Accessibility for beginners

Python's code is easy to read. It does not use complex syntax. Incomprehensible abbreviations, punctuation marks and special characters almost never occur. A beginner Django-developer will be able to write own and understand colleagues code.

Studying Rails is a bit longer proccess. It also doesn't have complicated syntax, but without learning it is hard to understand the code. However, having mastered the language, in the future it will be easier and more pleasant to work with: it is more flexible than Python, and Rails offers more useful tools for creating web applications than Django.



High-level, free and open source Python Web framework.

Django fully realizes the concept of Python, which is primarily based on the simplicity of the syntax and the ability to write quality code quickly. However, the framework itself requires a good knowledge of its internal structure and available capabilities: for determining the MVC and URL routes, you will need to use regular expressions, and all classes and variables must be explicitly written.

Ruby on Rails offers more ready-made solutions. A lot of actions are automated, for example, inheritance of methods. The same goes for definitions - there is no need to add classes and variables manually, the framework will do it yourself. On the other hand, this approach alleviates the life of the programmer, but does not make it clear how the application is built in detail.


Frameworks are created on the basis of scripting interpreted languages, so there is no big difference in speed. However, Ruby is still slower than Python, which affects the work of Rails. However, it will be noticeable only in high-loaded projects. The rest, most likely, will not feel the difference.

Availability of libraries

Perhaps the only parameter by which Ruby on Rails is unconditionally better than Django - there are more plugins and extensions for this framework than for Python. But this does not mean that Django will have to work without libraries at all. They exist, and there are many of them. However, RoR is still able to provide more.

Support for language and community developers

Django documentation is more detailed and completed, it is easy to find the answer to any question that arises. Rails has a less detailed and slightly worse structured help system. However, this does not greatly complicate the work with the language - you can not call the RoR documentation incomplete.

Both Python and Rails has a large, fully-formed community. However, it is not the same. An important difference of the Django community is its multi-profile. The framework does not have well-defined boundaries of application and can be used to create any applications. Ruby on Rails is designed for web development, so there are very few discussions in its community related to solving other problems.

Final comparison of Ruby on Rails and Django

Django Ruby on Rails
Simple syntax More complicated syntax
High performance Lower performance
Mandatory class and variable definitions Automatic definition of classes and variables without explicit definition
Creating MVC and URL Routines with Regular Expressions Automatic creation of MVC and URL routes
Small number of libraries Significant selection of extensions
Detailed documentartion Less detailed documentation
Suitable for creating any applications Suitable for web development

What framework do you like more?

In your opinion, what technology is the most interesting and has bigger future? Django is Python based framework with high performance but small nimber of availabe libraries and Rails are the Ruby framework with lower performance but with bigger selection of extensions.

DateTime, Timestamp, Time and Date in Rails

Learn about key differenece between DateTime, Timestamp, Time and Date in Rails
31 October 2017   606

The difference between different date/time formats in ActiveRecord have little to do with Rails and everything to do with whatever database you're using.

Using MySQL as an example (if for no other reason because it's most popular), you have DATEDATETIMETIME and TIMESTAMP column data types; just as you have CHARVARCHARFLOATand INTEGER.

So, main differences: DATE only stores a date, TIME only stores a time of day, while DATETIME stores both.

The difference between DATETIME and TIMESTAMP is a bit more subtle: DATETIME is formatted as YYYY-MM-DD HH:MM:SS. Valid ranges go from the year 1000 to the year 9999 and everything in between. While TIMESTAMP looks similar when you fetch it from the database, it's really a just a front for a unix timestamp. Its valid range goes from 1970 to 2038. The difference here, aside from the various built-in functions within the database engine, is storage space. Because DATETIMEstores every digit in the year, month day, hour, minute and second, it uses up a total of 8 bytes. As TIMESTAMP only stores the number of seconds since 1970-01-01, it uses 4 bytes.

You can read more about the differences between time formats in MySQL here.

In the end, it comes down to what you need your date/time column to do. Do you need to store dates and times before 1970 or after 2038? Use DATETIME. Do you need to worry about database size and you're within that timerange? Use TIMESTAMP. Do you only need to store a date? Use DATE. Do you only need to store a time? Use TIME.

Having said all of this, Rails actually makes some of these decisions for you. Both :timestamp and :datetime will default to DATETIME, while :date and :time corresponds to DATE and TIME, respectively.