Revisiting Django

I’ve written about the merits of Django before, but that was a long, long time ago. All this while, I’ve mostly been working in PHP and Laravel, and also had a chance to dip into Elixir + Phoenix. These days, I happen to be building a product in Django, and its database management prompted me to write this post.

More control vs less control is always a recurring theme in software development. Should you bow down to the conventions of the framework and move faster, or set up your own rules of the game and do it the “right” way? In Phoenix and Laravel, migrations are separate from models. You have to define both, and change in one causes a change in the other (not true about Laravel, but still you need to create and define model classes, set up $timestamps as false, etc.).

When I revisited Django, I felt like I was being taken for a ride. Wait, you will generate the migration files yourself and not show me a damned thing? How can I trust you not to screw up the whole database?!

It turns out my fears were unfounded. Django does a supreme job of managing database modifications. In fact, it was during the several rapid-fire iterations that Django’s philosophy (“A web framework for perfectionists with deadlines”) dawned on me. Before long, I got into the habit of blindly making rapid changes and hitting the `migrate` command. And it all worked.

Quite pleasant, if you ask me. I can now see why Ruby on Rails gained the following that it has. And of course, Django has gained several points in my book.

Leave a Reply

Your email address will not be published. Required fields are marked *