Python vs Ruby

Ruby is a dynamic, reflective, object-oriented general-purpose programming language which was designed and developed in the mid-1990s. Compared to Python, which treats code readability above everything else, the philosophy behind Ruby is that programmers should have the flexibility, freedom and power to write concise and compact code.

The most important difference between Python and Ruby is that the philosophy of Python requires almost everything explicitly defined by a programmer while Ruby allows the programmer to write code with implicit behaviour inherited from other components. For example, in Ruby, the self in instance methods is implicitly defined while Python requires self to be the first argument declared into an instance method.

[ruby]
class Hello
def hello
'hello'
end
def call_hello
hello()
end
end
[/ruby]

[python]
class Hello(object):
def hello(self):
return 'hello'
def call_hello(self):
return self.hello()
[/python]

In the example code above, the class Hello contains two instance methods hello() and call_hello(). Notice that Ruby's definition of call_hello() simply calls the hello() method without referring to self.hello() like Python's definition does.

Ruby on Rails Overview

Ruby on Rails, or simply Rails, is an open source web application framework which runs on top of the Ruby programming language. Just like Django, Rails allows a programmer to write web applications that talk to a backend database to retrieve data and render the data in templates on the client side.

Unsurprisingly, the implicit philosophy of Ruby also impacts how Rails was designed. Unlike Django, which forces the programmer to explicitly configure the project and express her intentions in the code, Rails provides lots of implicit default conventions that the programmer can rely on out of the box. Unlike Django, which is often flexible and does not enforce one way of doing things, Rails assumes there's only one best way of doing certain things, therefore making it very hard for a programmer to modify the logic and behaviour of Rails code.

Convention over Configuration

The most important philosophy of Rails is convention over configuration (CoC), which means that Rails projects have a predefined layout and sensible defaults. All components such as models, controllers, and static CSS and JavaScript files are located in standard sub-directories and you can simply drop your own implementation files into those directories and Rails will automatically pick them up. While in Django, you often have to specify where the component files are located.

CoC is a big win for the developer since it saves lots of time typing the same configuration code over and over again. However, if you want to customize your project's configuration, you have to learn quite a bit about Rails in order to change the configuration without breaking the whole project.

Model-View-Controller and REST

Rails is a Model-View-Controller (MVC) full stack web framework, which means that the controller calls functions from the model and returns the data back to the view. Although many web frameworks are also based on MVC, Rails is unique because it supports a full REST protocol out-of-the-box. All model objects are accessed and handled in an uniform manner using the standard HTTP verbs like GET, PUT, DELETE and POST.

Why Ruby on Rails

Like Django, Rails also uses models to describe database tables, and controllers to retrieve data from models and return the data to views who eventually renders the data into an HTTP response. To map a controller to an incoming request, programmers specify routes in a configuration file.

Since its initial release in 2005, Rails has become more and more popular among web programmers. Its easy to use and understand tech stack and implicit CoC philosophy seem to allow agile web programmers to implement applications faster than other frameworks. Therefore, Rails is a good alternative to Django.

Differences between Ruby on Rails and Django

So far, Rails looks almost the same like Django. Since Django's Model-Template-View can be treated as a variation of Model-View-Controller where a Django view is a MVC controller and a Django template is a MVC view, both Django and Rails endorse MVC and provide common web framework functionalities. You might start to wonder: Is there any difference between Rails and Django?

The most important difference is that Rails promotes the philosophy of convention-over-configuration, which means a developer only needs to specify unconventional parts of an application. For example, if there is a model class named Employee, then the corresponding table in the database is going to be named employees if the developer does not provide an explicit table name. If the developer wants the table to have a different name, which is unconventional, then he or she needs to explicitly specify the table name in the model file for Employee.

Rails runs on top of Ruby which values expressiveness and provides lots of implicit behaviour while Django runs on top of Python which values explicitness and could be more verbose. For example, Rails models expose an implicit method find_by on every model object which allows a programmer to find a database record by a model attribute. While Django does not expose such implicit methods on its models.

Besides the normal project generation script like Django's django-admin.py createproject, Rails offers a powerful scaffolding script that allows you to generate a new controller directly from the command line.

[shell]
$ rails generate controller welcome index
create app/controllers/welcome_controller.rb
route get "welcome/index"
invoke erb
create app/views/welcome
create app/views/welcome/index.html.erb
invoke test_unit
create test/controllers/welcome_controller_test.rb
invoke helper
create app/helpers/welcome_helper.rb
invoke test_unit
create test/helpers/welcome_helper_test.rb
invoke assets
invoke coffee
create app/assets/javascripts/welcome.js.coffee
invoke scss
create app/assets/stylesheets/welcome.css.scss
[/shell]

The command above created several files and a URL route for you. Most of the time, you only have to insert custom logic into the controller implementation file in app/controllers/welcome_controller.rb and the view implementation file app/views/welcome/index.html.erb.

Unlike Django, which has built-in user authentication and authorization support, Rails does not provide authentication service out-of-the-box. Fortunately, there are lots of third-party authentication libraries available. You can check them out at rails_authentication.

A downside of Rails is that its API changes more often than the Django API. Therefore, backward compatibility is often not preserved in Rails while Django rarely changes its API and maintains backward compatibility.

Hosting support and Development tools

Due to their undeniable popularity, both Django and Rails have excellent hosting providers such as Heroku and Rackspace. Of course, if you'd like to manage the server by yourself, you can always choose a VPS provider to host your Django or Rails application(s).

If you ever run into issues with Rails, the official website rubyonrails.org provides great resources for finding information in the documentation and you can ask questions in the community forum.

Summary and Tips

Both Rails and Django are effective web frameworks powered by efficient programming languages. At the end of the day, the choice is entirely subjective and personal and neither one is better than the other. If you are going to work at a company who uses one of these two frameworks, I recommend talking to the developers at that company and choosing one that almost everyone is excited about.