Getting Started with Django: A Practical Overview of Its Key Features

Hello! There's something uniquely satisfying about picking up an old, established technology that has been solving real problems for over two decades. Django, a Python web framework, is one such gem. I recently dove into Django to build a website, and I've been impressed by how straightforward and maintainable it feels. Unlike some frameworks that rely heavily on convention and 'magic,' Django lets you be explicit about your code, making it easier to pick up projects after months away. Below are some of the most notable aspects I discovered, presented as questions and answers to help you get started.

Why does Django feel less 'magical' than Rails?

Both Django and Rails are powerful, but they differ in how they handle conventions. Rails uses implicit conventions—like a resources :topics line in routes.rb—which can be cryptic when you revisit a project after several months. You have to remember or look up the underlying routing patterns. Django, on the other hand, keeps things explicit. In a typical Django project, you work with five main files: urls.py, models.py, views.py, admin.py, and tests.py. Any HTML templates or other resources are usually referenced directly from these files. This means if you step away from a project for a year, you can quickly trace where everything lives without relying on hidden assumptions. For developers who value clarity and long-term maintainability, Django’s explicitness is a major win.

How does Django’s built-in admin interface work, and how can I customize it?

Django comes with a fully functional admin interface that lets you manually add, edit, and view database records. It’s a huge time-saver for prototyping and internal tools. Customization is straightforward: you define an admin class for each model. For example, to display a list of zines with specific fields, you can override list_display, search_fields, and ordering. Here’s a snippet from one of my projects:

@admin.register(Zine)
class ZineAdmin(admin.ModelAdmin):
    list_display = ["name", "publication_date", "free", "slug", "image_preview"]
    search_fields = ["name", "slug"]
    readonly_fields = ["image_preview"]
    ordering = ["-publication_date"]

With just a few lines, you get a tailored list view, search functionality, and custom read-only fields like image previews. This makes the admin an incredibly flexible tool for managing data without building a separate front end.

Why might someone enjoy using Django’s ORM instead of writing raw SQL?

If you’ve always been a “raw SQL” purist, Django’s ORM might surprise you. It abstracts away repetitive SQL while still giving you powerful query capabilities. One particularly elegant feature is the use of double underscores (__) to represent joins across tables. For instance, Zine.objects.exclude(product__order__email_hash=email_hash) traverses five tables—zines, zine_products, products, order_products, and orders—with a single line of Python. Behind the scenes, Django’s ORM automatically handles the joins based on the relationships you define, such as ManyToManyField. This approach keeps your code clean, readable, and less error-prone than writing complex SQL by hand. Plus, you get the benefit of database portability: the same ORM code works on SQLite, PostgreSQL, MySQL, or any supported backend.

What are the main files in a small Django project?

In a typical Django project—excluding configuration files like settings.py—you’ll often find five core files that define your application’s logic:

• urls.py – Maps URL patterns to views.
• models.py – Defines your database schema as Python classes.
• views.py – Contains functions or classes that handle requests and return responses.
• admin.py – Registers models with the built-in admin interface.
• tests.py – Holds unit tests for your application.

This explicit file structure is one reason Django is so easy to navigate after a long break. If you need to find a template, it’s likely referenced in a view; if you need to change a database field, you go to models.py. There’s no guesswork or hidden “magic” that forces you to memorize conventions.

How does Django handle database relationships like many-to-many?

Django ORM simplifies relational mappings through fields like ForeignKey, OneToOneField, and ManyToManyField. For example, to link orders and products with a many-to-many relationship, you define a field in one of the models and Django automatically creates an intermediary join table. You can then query across the relationship using the double-underscore syntax. The original article’s example Zine.objects.exclude(product__order__email_hash=email_hash) demonstrates how easily you can traverse multiple related tables. You just need to declare the relationships once in your models, and Django handles the rest—no manual SQL joins required.

Why is Django great for projects you abandon for months at a time?

Many side projects get shelved for weeks or months. Django’s design philosophy supports this scenario well. Because the framework favors explicit over implicit, you can quickly reacquaint yourself with the project’s structure. The clear division of responsibilities across urls.py, models.py, views.py, admin.py, and tests.py leaves little room for confusion. Additionally, the built-in admin interface provides a ready-made back end, so you don’t need to remember custom admin panels. If you come back after a year, you can open the project, look at the main files, and understand how data flows. This predictability makes Django a strong choice for hobbyists and professionals who juggle multiple projects over long periods.