Django is for everyone.

Django is great even for “small” websites

I think people tend to consider Django either for building old-school, industrial-strength monolith apps or for APIs and using something like React for the front-end. I’m here to tell you that plain old Django is a great option even for your personal websites! In my opinion, if you need a database, you should use Django¹.

Why Django?

Django is considered a “batteries-included” framework, and those batteries are awesome. These are the things that keep me using Django over any other framework.

The Object-Relational Mapper (ORM)

The Django ORM is a huge reason to use the framework. I’m flabbergasted that not all web frameworks include an ORM. Unless you’re a huge fan of writing SQL from scratch, this is the right way to build apps. You define models, you create database migrations from those models (mostly automatically), run the migrations on your database and you’re good to go! No writing half-assed models plus a series of migrations where you can sort of extrapolate the schema². All the information you need about your data is in your models.py file and everything flows from that.

The Admin

This is the big one. It’s not a CMS; it’s more of a GUI for the ORM. After you define your models you can, with very little configuration, manage that data without having to write any CRUD code. It’s not the front-end of your application. It’s not a CMS for end-users (probably). It’s a way for administrators to easily make changes to the site.

Progressive Enhancement

This is very near and dear to my heart, but most of the rest of our industry seems to have forgotten. Simply put; base-level functionality should be possible even when JavaScript fails. Your app should be able to at least limp along without front-end scripting. Doing that with a SPA is a nightmare. Doing it with a real backend framework plus a tool like htmx or Unpoly is trivial. You just have to change your perspective from the status quo to common sense.

Concepts to keep in mind

MTV

While traditional application frameworks use the Model, View, Controller design pattern; Django names their elements a little differently.

• Model
  • Ok, this one is the same.
• Template
  • This is equivalent to the traditional View.
• View
  • This is mostly equivalent to the traditional Controller.

Database Migrations

This is a solved problem in Django. It’s really nice! There’s lots more to know about it, and you should look at the generated migration files before running them, and there are times when you’ll need to do this stuff more manually, but this is the crux of using it:

./manage.py makemigrations
# It tells you what it did. ./manage.py migrate
# Database updated!

That’s it! 🎉

How to get started

Blaze.horse

Here’s where I shill for my own little project. The good news for you, solo developer that I imagine is reading this, is that it’s free for non-commercial use. If you end up using it and it helped you build a commercial application, it’s only $100 USD one time. C’mon, that’s quite a value!

Even if you don’t end up using the whole kit, I urge you to look over the techniques I use in the code. That’s hard-won stuff after using Django almost since its beginning. I went through a phase of using it with Docker and Postgres, but I really believe this is the way for 99% of folks who want to give Django a try. SQLite is amazing.

Deployment

Unfortunately, this is the main downside of choosing Django over other options targeted at personal websites. With Blaze.horse, I’ve tried to set you up for an easy time, but it’s still fiddlier than it ought to be. There are some up-and-coming projects that give me hope, such as Button and Appliku, but I’m personally happy with Fly for now.

Next steps

After reading this, I hope you’ll keep Django in mind the next time you need build something. Let me know if I can help!

1. If you need a CMS, you should use Kirby. You certainly shouldn’t be using a static site generator if you need a CMS. FFS ↩

2. Laravel ↩