Why Django?
Before installing anything, it's worth spending a few minutes on why Django looks the way it does. A framework isn't just a pile of code — it encodes a set of opinions about how web applications should be built. Understanding Django's opinions up front will save you a lot of "wait, why does it work like that?" moments later in this track, especially once we start wiring up the models, views, and templates for our running example app, TaskFlow.
The "Batteries Included" Philosophy
Django was born out of a real newsroom's need to ship web applications on tight deadlines, and that history shows in its design. Rather than handing you a bare routing library and leaving you to shop around for a database layer, a templating engine, a login system, and an admin tool, Django bundles all of it into one cohesive package. The idea is simple: the parts of a web app that are the same in almost every project — talking to a database, validating form input, showing an admin screen, keeping user sessions secure — shouldn't have to be reinvented or re-evaluated on every project.
- An ORM (Object-Relational Mapper) for working with your database using Python classes instead of raw SQL
- A full admin interface generated automatically from your data models
- A forms library for validating and rendering HTML forms
- An authentication system for user accounts, login, logout, and permissions
- Built-in protections against common security issues like CSRF and SQL injection
The trade-off is that Django has more moving parts to learn up front than a minimal framework. But for a project like TaskFlow — which needs user accounts, a database of tasks and projects, and eventually an admin screen for managing them — that upfront investment pays for itself almost immediately.
The MVT Pattern (and How It Maps to MVC)
Django describes its own architecture as MVT: Model, View, Template. If you've worked with other web frameworks before, you've probably heard of MVC: Model, View, Controller. These two names look almost identical, but the middle letter means something different in each one — and that mismatch trips up a lot of people coming to Django from another background.
- Model — in both patterns, this means the same thing: the layer that represents your data. For TaskFlow, this is where
Task,Project, andTaglive. - Django's View — a Python function or class that receives a request, decides what needs to happen (fetch some tasks, save a form, check permissions), and returns a response. This is logic, not markup.
- Django's Template — the HTML file, sprinkled with template tags, that actually gets rendered to the browser.
| Classic MVC term | Django's term | What it actually does |
|---|---|---|
| Model | Model | Represents and manages your data (identical concept in both) |
| Controller | View | Contains the logic: what to fetch, what to compute, what to return |
| View | Template | The actual HTML/markup that gets displayed to the user |
Django vs. Flask vs. FastAPI
Flask and FastAPI are both excellent Python web frameworks, but they take the opposite approach from Django: they're intentionally minimal, giving you routing and not much else, so you pick your own database library, your own auth solution, and your own admin tooling (if you want one at all). Here's an honest side-by-side comparison:
| Aspect | Django | Flask / FastAPI |
|---|---|---|
| ORM | Included and tightly integrated | Not included — you add SQLAlchemy or similar yourself |
| Admin panel | Generated automatically from your models | Not included — you'd build or bolt one on |
| Authentication | Built-in user model, login views, permissions | Not included — you choose and wire up a library |
| Routing style | Centralized urls.py per app | Decorators directly on route functions |
| Async support | Supported, added on top of a mostly sync-first design | FastAPI is async-first by design |
| Best suited for | Full-featured apps: content sites, dashboards, internal tools, e-commerce | Small services, microservices, high-throughput APIs |
| Learning curve | More to learn up front, but less to decide | Quicker to a "hello world", more decisions later |
Neither approach is objectively "better" — they optimize for different things. Django optimizes for getting a complete, secure, data-backed application running quickly with sane defaults. Flask and FastAPI optimize for minimalism and letting you choose every piece yourself.
Who Actually Uses Django?
Django isn't just a teaching framework — it has powered large, high-traffic products for years:
- Instagram famously scaled Django to serve hundreds of millions of users, proving the framework holds up well past "small project" scale.
- Spotify has used Django for backend and internal tooling services as part of its broader Python usage.
- Mozilla runs some of its web properties, including parts of its add-ons ecosystem, on Django.
This matters less as "appeal to authority" and more as reassurance: the patterns you're about to learn for TaskFlow — models, views, templates, the admin — are the same patterns running in production at real scale, not toy-project shortcuts you'll have to unlearn later.
When Django Is a Great Fit
| Situation | Why Django fits well |
|---|---|
| Content-heavy sites (blogs, news, documentation portals) | Django's templating, URL routing, and admin make managing lots of structured content straightforward |
| Apps that need an admin panel fast | Registering a model gives you a working admin screen almost immediately, no separate build required |
| Teams that want strong conventions | Django's "there's a standard way to do it" approach keeps codebases consistent as teams grow |
| Internal business tools | Apps like TaskFlow — task/project tracking, approvals, dashboards — are exactly Django's sweet spot |
| Apps needing solid auth & permissions quickly | User accounts, login, and permission checks are built in rather than assembled from scratch |
When a Lighter Framework Might Fit Better
To be fair to the alternatives, there are real situations where reaching for Django is more than you need:
- A tiny microservice that does one narrow job (say, a webhook receiver that only writes one row to a database) may not need an ORM, admin site, or auth system at all.
- Extremely performance-critical APIs with heavy concurrent I/O may benefit from FastAPI's async-first design, especially if you don't need most of what Django ships with.
- Extremely small teams or solo scripts that just need a couple of endpoints might find Django's project structure (settings, apps, migrations) like more scaffolding than the task warrants.
Introducing TaskFlow, Our Running Example
Throughout the rest of this track we'll build one connected application together instead of jumping between disconnected snippets: TaskFlow, a small task-management app. It will eventually have:
- A Task model — title, description, due date, priority, a completed flag, a link to its project, and a set of tags
- A Project model — name, description, and an owner (a link to Django's built-in
Usermodel) - A Tag model — just a name, used to label tasks across projects
You'll see exactly why Django's model and admin layers are such a good fit for this kind of data
once we start writing the actual models.py file a few lessons from now.