I applied for a company this week that was hiring for a Python position. Python was the first language I ever learned and I felt very comfortable with the syntax, but I hadn’t yet used it to build a project. I got in touch with one of their employees who told me that the company would consider me if I was able to build a project with Django by the time they started kicking off interviews.
While I didn’t wind up getting the interview, I did take him seriously and whipped together a basic polling app over the next couple of days. The exciting part for me is that Django was the last of the three mainstream back-end web frameworks that I hadn’t yet been exposed to, the other two being Express.js and Ruby on Rails.
I’m definitely still in the early stages with Django, but I’ve now spent enough time with it that I can thoughtfully consider the advantages and disadvantages of all three frameworks when making decisions on how to architect my server-side projects.
Ruby on Rails
Rails is so simple to use once you get past the initial learning curve. Complex models and migrations are easily composable from the command line, and Rails’ built-in ActiveRecord ORM allows you to define complex relationships between several models in minutes. Since Rails comes packaged with SQLite3 by default, you don’t need to spend time configuring your database connection in development unless you’re wanting to use a NoSQL database like MongoDB. Rails follows a ‘convention over configuration’ philosophy and development becomes lighting fast once you learn the conventions. It’s a great framework for beginners looking to get their feet wet with back-end web development.
Rails is a very opinionated framework, having specific rules about where most things should be and how most things should work. This is great for when you’re wanting to build a basic CRUD API to communicate with your front end, but the strict adherence to following certain rules makes the framework feel more difficult to customize. The starter templates come with a ton of directories that make the app feel large and monolithic before you’ve even written a single line of code. Rails performs a little more slowly than other back-end frameworks, which is probably one of the main explanations for its decline in popularity over the last couple of years despite its massive community.
Developers describe Express as being a “lightweight” framework. Since Ruby on Rails was the first framework I ever learned, the benefits and advantages of knowing a lightweight framework like Express were immediately apparent. While frameworks like Rails and Django give you a ton of toys right out of the box, Express’s minimalistic approach gives you total control over the feel and customization of your server. This is critical when you are dealing with an app that doesn’t follow normal conventions and needs to behave in a very specific way.
It’s hard to point out a lot of the disadvantages to using Express, because the main “disadvantages” could just as easily be viewed as positives or features. Since Express basically just gives you the ability to start your server and define your routes, any other layers you choose to implement such as authentication, data validation, database integration, ORM, etc. are entirely on you. This can be a little intimidating for beginners, so you’ll want to make sure you have a good understanding of the common “parts” that make up an API if you choose Express as your first framework. Two of the most commonly used ORMs in Express are Sequelize and Knex.js, and in my experience, the built-in Rails and Django ORMs were both better documented and easier to understand.
Django follows the ‘convention over configuration’ philosophy and similar to Rails, the conventions make it easy to spin up basic apps very quickly. Django seems to bring together the best of both worlds between Express and Rails, offering the developer just enough freedom to be dangerous but providing enough of the right tools to help automate common tasks. The documentation is extensive and very well-written. By following the walk-through on the website, I went from knowing nothing about the framework to building a basic polling app in a day. Django does require a little more configuration than Rails, but the file system doesn’t seem nearly as bloated and is far easier to navigate.
Django uses regular expressions for route handling. The structure isn’t complicated, it’s just the syntax that might take some getting used to, especially for beginners. The way Django handles its file system is also a little weird at first, as you’ll frequently find yourself nesting directories inside of other directories that share the same name by necessity. Django seems to be perfect for medium-sized projects; a little too heavy-duty for a smaller app, but becomes more challenging to manage as you add more components to your app (all of your models, for example, have to be at the same level in the same directory, which can make models difficult to organize if you have a lot of them).
I’m glad that I learned Rails first as it gave me a good big-picture view of the key components that make up back end development. That said, it was when I started working in Express that I grew the most as a developer — removing the “training wheels” that Rails provides forced me to understand how all of the parts of an API work on a deeper level. There are a ton of libraries that work very well with Express, so there are a variety of ways to find a stack that works for your situation. I imagine I’ll find myself defaulting to Express more times than not, unless I’m in a situation where I need a standard API with basic CRUD capability quickly, in which case I’d prefer Django.