When it comes to Object-Oriented Programming (OOP), two languages stand out from the pack in terms of maturity, community and worldwide use, namely Ruby and Python. And since a large portion of programming languages are used in conjunction with web development, we have to discuss their respective web frameworks: Ruby on Rails and Django.
But which framework is best suited for you in 2021?
You can think about web development as any application that is intended to be used directly over the internet. Depending on what your company’s needs are and the resources available to you, some choices become more apparent than others. As with traveling – where you can choose from multiple routes and means of transportation to reach your destination – so do programming languages offer different means of achieving the same desired outcome.
Some notable differences between various languages include functional programming vs. OOP programming and declarative vs procedural programming (derived from imperative programming ).
These represent different flavours of programming and encompass unique quirks and features. But, much like how debating which is better out of vanilla and pistachio ice cream is meaningless since it is a question of taste, so is comparing functional vs. OOP.
However, if you know you like pistachio ice cream, comparing which brand offers the best pistachio ice cream is a worthy pursuit, hence today we will discuss the comparison between Django and Ruby on Rails.
Main similarities between Django and Ruby on Rails
First of all, both of these are web frameworks and should not be confused with their respective languages. A web framework (WF) or web application framework (WAF) is a software framework that is designed to support the development of web applications including web services, web resources, and web APIs – basically any application that is designed to be used over the web and as such adheres to web protocols and standard practices.
Both of their underlying languages are OOP languages, meaning that they are used to create objects that pass messages since everything is an object in OOP. Note: If you’re unfamiliar with what OOP is, in short, the whole idea behind OOP is passing messages and that every object doesn’t care who the message receiver is or who the message sender is. This means that objects can change behavior depending on what messages they work with. That is the whole basis of polymorphism.
Communities behind Django and Ruby on Rails
What this means is that you can be sure when you hit a wall during development – a bug, unexpected or unwanted behavior, or even not knowing what direction you should go in – you can easily search for your issue online and find plenty of solutions, examples, and recommendations. And the best part is that, for most issues documented and resolved, there is community consensus. You never have to worry about “picking the right answer” to your problem.
Because of these communities and their consensus on how things should be done, both frameworks offer bootstrapping tools in the form of commonly used libraries and packages for resolving specific issues.
Plenty of libraries for Ruby on Rails and Django
These external libraries come in the form of “gems” in Rails and “packages” in Django. The installing procedure and syntax is extremely similar.
For example, if you want to add user authentication in your Rails application, all you need to do is:
For Django, you would use the ubiquitous pip install command (preferably with pip3):
Note: Bundle install is a command of the tool Bundler, which is also a gem – a gem that manages gems in Rails.
Language version management for Django and Rails
Another cool similarity is environment control… well, sort off.
Working on multiple projects at once can be difficult regardless if they are in Django or Rails since dependencies often change depending on the project. One notable dependency is the language version.
It is true that Ruby and Python are singular languages, but each one in part hosts multiple versions of themselves. And sometimes switching projects without switching language versions in your system environment can break your work – unless you are using Docker.
To solve this problem, the ruby community uses version managers, the most popular two choices being
rbenv, the latter being the more recommended one.
pyenv is the preferred tool of choice.
Other noteworthy similarities
Major differences between Ruby on Rails and Django Framework
We already touched upon the main difference between the two frameworks as being the underlying languages.
Short history lesson: the initial idea behind Python came about in the late 80’s from Guido van Rossum in the Netherlands. The intent was to have a language capable of exception handling and interfacing with the Amoeba operating system.
On the other side, Ruby was birthed in the mid-90s in Japan by Yukihiro “Matz” Matsumoto, who wanted something more serious than Pearl and “more object oriented” than Python. In 1999, Matz was quoted as saying, “I knew Python then. But I didn’t like it, because I didn’t think it was a true object-oriented language – OO features appeared to be an add-on to the language.”
Fast forward to 2021 and the current stable versions available for both languages are Ruby 3.0.0 and Python 3.9.2
The differences in numbering come about from how many major and minor releases both language developers have made since both languages took decades to arrive at their current iteration.
There aren’t many differences when it comes to user interface. I mean, there are differences between Django and Ruby on Rails, but more of a flavor difference rather than a type difference.
Both are very heavily adapted to handle all free market requirements for 21st century web development. When it comes to web frameworks, chances are if it’s something you cannot do with Django or Ruby on Rails, it’s not really something that can be done.
So it’s more a question of taste which you should choose when it comes to their respective interface. You should experiment with both to get a feel for them and make a decision afterwards.
Back in the 80s and 90s, developer time was cheap and processor time was expensive. Every problem encountered was in similar parts an issue of hardware as much as software.
Fast forward to the present and the situation is the inverse. With such high human resource costs and how hard it is to attract new developers, the developer time has become significantly more expensive as opposed to the new generation style of hardware available that provides super fast run times, computational power, and hosting solutions.
However, just because computers and servers nowadays can “handle it”, that doesn’t mean that we should be sloppy. As such, when it comes to speed, both frameworks and underlying languages perform very well, taking into account their scope of use. But if you must be excessively picky, it was observed that Rails is slightly faster, even if by a very small margin.
How many people actually enjoy setting up environments? Well, if you go by the ever-increasing popularity of containers – and I’m speaking about Docker here – then apparently not a lot.
How fast – in a download-to-develop sense – are you really with either platform?
Well, it is a matter of luck to be brutally honest. If everything goes smoothly, both are very easy to install and set up by following their respective installation guides. And where Rails will have you installing gems, Django will have you installing packages.
But much like how setting up Django on Windows or MacOs might be different than on Linux, so can differences appear between both frameworks on the same machine. It depends on the machine and on the requirements – aka dependencies – you need for your specific task. Do you want a certain type of database setup? Is it an Sql database or a NoSql?
And this goes further down depending on which specific database you want. Do you need to perform simple straightforward user interactions on your app or do you maybe require handling big data sets, and even analyzing and interpreting them? If so, you will need to research beforehand what libraries are currently available for both frameworks. And depending on what libraries there are and what dependencies each of them has, then initial installation and configuration can quickly become burdensome. So you cannot really answer the question of which is faster to set up. But it’s fair to say both can be equally as simple or as frustrating to get started with, depending on your particular circumstances and luck.
Availability of documentation and user references
Both frameworks have very large communities behind them and as such there is a plethora of user references, documented user experience, and also community driven guides and guidelines – all to facilitate ease of use and ease of understanding. On the official side, since both underlying languages and frameworks are old enough to be considered mature (through and through), it comes as no surprise that both offer extensible, well maintained, and up-to-date documentation.
This documentation coverage ranges from installation and download, which are very generic issues, to edge case scenarios.
It is safe to say that no matter what framework you choose, you will never be in the dark when it comes to functionality, expected results, edge cases, gotchas, and the like. Whether with Django or with Rails, you will never feel alone in your development career.
Flexibility of use
Python is the darling of the academic world when it comes to data science, and that makes sense when you think of the relationship between Python and the graphics card industry.
So if your webapp is designed to center around big data sets, machine learning, and all that crowdfunding terminology, then you should go with Django so as to be able to leverage all the existing libraries that already tackle those issues.
If you focus on the custom things you need to apply your business domain knowledge, how you manipulate data from your database, and all the cool tricks you need to distinguish your app from your competitors, then you should go the Rails route. Its developer-centered philosophy and flexibility of use – with metaprogramming, DSLs, and syntactic sugar – gives your engineers significant freedom and fun when developing. Caution though: Rails gives you enough rope to either have fun or really hurt yourself.
Python is fairly easy to pick up and learn, but difficult to master – as with all things worthwhile – and as such Django follows behind with the same curvature. It is a great first language and a great first framework.
It also works great if you decide to switch fields and pick it up after years of, let’s say, Java or PHP.
Rails has a whole philosophy behind it. If you are in tune with it, it is very easy to pick it up – maybe even easier than Django. The caveat is that you must first understand the philosophy behind it. Things like “Convention over Configuration” and “DRY” (Don’t Repeat Yourself) are cornerstones of “The Rails Way”, to name a few.
This underlying philosophy with its guiding principles and specific way of doing things takes time to rummage around and adopt. This is also why plenty of people recommend Rails to more seasoned developers, people who know the pain of programming and the realities of the industry, and as such are equipped with the necessary background or experience to very easily adopt the Rails Way.
The driving force behind the technology
Have you ever had the feeling that maybe, just maybe, a specific language shouldn’t exist? Or worse, wonder in awe at the large scale popularity of a tool that makes no empirical sense? I’ve had that same feeling, and it drove me to research and understand – at least on a superficial level – the historical reasons why some languages succeeded where so many others failed.
PHP is a scripting language first and, loosely defined, a general purpose language secondly. But why did it ever achieve popularity despite its many quirks and flaws? Simply put, it was in the right place at the right time – namely, the dot com bubble.
A lot of the dot com bubble sites and online pages were done with PHP, and any language that is widely used at one point in time is guaranteed to stick around for a long time to come.
C is the de facto language for creating other languages. To make a new language, you need a language parser, and these are done in C. Ruby is written in C and so is Python. So as long as computer languages are needed, so will the need to use C be.
Why did Django gain popularity?
Python was picked up as a study and teaching language in universities for a variety of good reasons. When the same universities got grants for research in AI, NLP (Natural Language Process) and Big Data Analysis, the language for their research was Python. When graphics cards started being heavily used for data science through GPU computing, Python became the obvious choice. As such, the most popular and diverse libraries for data science are available in Python. The same is true for GPU computing on graphics cards, where Python is obligatory as well.
Since Python is so popular and so many new developers pick it up, its de facto web framework, Django, is and will continue to be extremely popular as well.
Why did Ruby on Rails gain popularity?
Before Rails appeared, Ruby was a mostly unknown language, especially outside of Japan. It was used then, as it is now, in the Japanese automotive industry for embedded Ruby solutions. You could also make a point that it made sense for Japanese manufacturers to use a Japanese programming language either out of pride, a nationalistic sentiment or for security reasons.
When D.H.H. – David Heinemeier Hansson – presented Ruby on Rails in 2004 and showcased how you can launch a working web app in under 2 hours, the industry went crazy. You can still find the video of the first presentation of Rails online and I recommend watching it.
What D.H.H. did back then, and still does to this day, is keep a very close eye on free market requirements and generate tools to speed up development in a fast and straightforward manner. It is also the main reason behind the “Rails Way” – the philosophy behind Rails and how to use it.
It also helps that Ruby has a similar underlying philosophy powering it and as such synergizes so well with Rails.
The main reason why Rails is popular is because the free market made an informed decision that Rails is the best solution for their problems at hand. Its popularity is dictated by charm, ease of use and the camaraderie in the world wide online community.
What should you pick?
If this were a perfect world and time was of no constraint, then the obvious choice would be to pick both.
You will grow way faster and stronger as a developer if you experiment in a production environment with more than just one language or framework.
But if you are like me, and everyone else on Earth for that matter, and lack the time to indulge in everything that is new and interesting, then you will have to make your choice based on the realities you live in. Some things to help guide your choice may include:
- Personal reasons:
- Technical reasons:
You have to be mindful of these same reasons if you are planning to launch a startup.
Usually startups are the type of business entities where the rules of engagement are not clearly defined, especially in the first couple of years. This means that usually the founders are the ones that handle most of the initial requirements, including the language skills necessary to develop the app.
That being said, you have to take into account the availability of talent when picking a tech stack. Simply put, if you are a Django developer, but there are no other available Python or Django devs in your area, then this is a clear sign that you will have a hard time finding and hiring help. The same applies for Ruby on Rails developers.
This is also the main reason why so many companies look for remote devs. The advantage is that there is a big pool of worldwide talent that is used to work in a fully distributed and asynchronous environment, so you can cast a big net.
The disadvantage is that you cannot work face-to-face. You will have to do a cost-to-benefit analysis on this aspect and see what fits best for your company. In short, it is recommended that you stay in the realm you are familiar with. If you have a background in OOP, pick an OOP tool. If you are a Django dev by trade, go the Django way. If you have Rails devs in your team, pick Rails as the tool for your new project or startup – better the devil you know than the devil you don’t.
Successful business apps powered by Django
Successful business apps powered by Ruby on Rails
If you’re interested in a further comparison of web frameworks, be sure to check our articles: