If you’re a new developer, you may have started off your web development journey by learning Ruby on Rails. Rails is a great starting point, but maybe you now want to expand your horizons a bit and learn a new framework.
Django is a good choice of a web framework, to extend your knowledge with. It’s well established and well supported with lots of resources out there to help you learn. Here’s some of the basics that you’ll need to know before getting started.
Django is written in Python which makes it a particularly excellent choice if you want to integrate an application with data science tools.
There are a few things that make the Django framework harder to work with than Rails. In some ways, these make it more difficult to use for beginners, though in my opinion, they are ultimately not much more challenging.
Rails is an MVC framework. Models, Views, and Controllers are clearly defined in Rails. Django, on the other hand, is not explicitly an MVC framework, although you can change some of the terms around to get something fairly similar to MVC.
So here’s a translation of each of the major parts of MVC into Django’s terminology:
You can see why Django is confusing now. What Rails calls a
controller, Django calls a
view. Django views perform roughly the same function as Rails
controller actions, though. Each Django
view processes a request and returns a response. There are technical differences between how Rails
controller actions work and Django views, but the analogy is pretty solid.
Rails has a nice little DSL for defining routes to controller actions. Django developers, however, usually have to specify how each route maps to each view.
A few years ago, Django developers had to use regular expressions to describe url paths. If you’ve ever had to work with regular expressions you didn’t understand, you can imagine how frustrating that could be.
Fortunately, these days Django has become more user-friendly and has made crafting url paths somewhat easier (but still not as convenient as Rails).
Part of the reason Django’s routing is more difficult to understand is that Django does not follow Rails’ convention over configuration mentality. Rails expects developers to follow standard conventions, allowing rails to do some of the hard work for the developer.
Don’t let Django’s greater difficulty deter you from trying it out, though. Django has some huge advantages over Rails in other areas.
Rails developers have to run highly specific commands and write some boilerplate code to tell Rails how to change tables in the site’s database. Django developers, however, don’t often have to worry about writing migrations because Django takes care of migrations under the hood.
Django models are written entirely in python code. When Django detects that a model has been changed, it’ll warn the developer that it’s time to make migrations. Actually creating the migrations is a super simple process: just run a single command:
python manage.py makemigrations
Django will then figure out what’s changed in the model and update the schema accordingly.
As a side note, the fact that Django models are written in Python is something I really appreciate because it means if I ever have questions about the current schema, I don’t have to open up a schema file and sift through unintuitive lists of ruby commands. Instead, I just open up the model I want to know about and the answer is right there.
If you’ve ever had to deal with authentication in Rails, you know that it can be super confusing the first couple of times. (What is BCrypt and how do I get it to hash the password correctly, again? And once I have gotten all that sorted out, how exactly do I keep track of a user’s authentication status across requests?)
Django comes with an authentication system right out of the box. Django has a robust User model that already takes care of password hashing and authentication. Django even gives you views and templates to handle user registration, logging in, password resets, etc.
Django also has an authorization system right out of the box to help developers control which users have access to which resources. Compared to Rails, this is a huge advantage, because in my opinion an application framework should have expectations regarding how authorization should work.
In fact, Rails’ lack of an authorization is such a problem, that I actually wrote my own authorization library which is available on RubyGems.
There are other solutions for authorization for Rails, but I designed mine to be extremely lightweight.
Django has a built in administration site which developers can use to interact directly with the data in the database, allowing developers to create, update, and delete objects with ease. Granted, the Rails console allows developers to do many of the same things, but the fact that there is a pre-built dedicated site for administration is a huge advantage if a non-programmer team member needs to make some adjustments.
In my opinion, it really depends on the context to decide which is better.
If you need to build an app in a really short time, rails might be the better option, as it is often quicker to build an app in Rails than in Django.
On the other hand, if you need more flexibility than a RESTful application, Django might be a better choice as it doesn’t make any assumptions about what you’re building.
If (for some reason) you need your application to run on a Windows server, then Django is probably a better choice. Rails and Windows do not play nicely together in my experience.
But if all you need is a small application that won’t have a lot of users and does one main job, rails could be sufficient. It all depends on what you need.
I hope you’ve found this guide useful, and I’d be happy to try to answer any questions you might have in the comments.