Some notes on starting to use Django

LLMs, Django, and HTMX

  • Several people report great experiences using Claude (and similar tools) to scaffold Django CRUD apps, especially with HTMX and Tailwind.
  • HTMX is seen as a good fit because behavior is attached directly to HTML elements, which LLMs handle well.
  • This stack is described as powerful yet simple, avoiding SPA-style complexity.

Django as Productive “Boring Tech” & Project Longevity

  • Many praise Django as extremely productive, stable, and backwards-compatible, with “enough batteries included” (ORM, admin, templating, etc.).
  • Its predictability and slow, incremental change are considered ideal for projects you can abandon for months/years and resume.
  • Commenters tie this to habits like automated tests, CI, documentation, and even formal requirements documents to make long-term maintenance feasible.

Complexity, Scaling, and Architecture

  • One view: Django/DRF are great for simple–moderate CRUD, but become limiting in highly complex, multi-threaded, high-scale systems.
  • Counterpoint: large, high-traffic Django monoliths can scale well if you understand the ORM, use query planners, select_related/prefetch_related, materialized views, and offload heavy work to other services or workers.
  • Emphasis that “Django is just Python”: you can split out async APIs, background workers, and message-bus architectures while retaining Django for models and migrations.
  • Some use auxiliary tools like django-ninja (thinner API layer) or iommi (faster CRUD scaffolding).

Migrations and Zero-Downtime Challenges

  • Strong praise for Django’s autogenerated migrations and ORM “happiness factor”; many say they almost never need manual schema migrations.
  • Others prefer fully manual migrations (e.g., in Elixir/Ecto) to catch bugs and better reason about complex schemas.
  • Concerns raised about edge cases with Django’s migration phases, data migrations, and zero-downtime rollout; solutions involve multi-stage schema changes, treating schema as append-only, specialized libraries, or accepting tiny error windows.
  • Some are wary of auto migrations; others note Django lets you inspect SQL, run raw SQL, and override operations.

SQLite and Backups

  • Discussion around VACUUM INTO vs copying the SQLite file directly.
  • Copying is fine when the DB isn’t active; VACUUM INTO (or the official backup API) avoids corruption while the DB is in use.

SPA/JSON vs Server-Rendered UIs

  • One commenter sees little reason to do more than “emit JSON” and use JavaScript for everything.
  • Others argue many apps are simpler and more maintainable with server-rendered pages plus light enhancement (HTMX/Unpoly).
  • Python preference alone is cited as a valid reason to choose Django, often combined with DRF/django-ninja for clean JSON APIs.

Settings, Configuration, and Validation

  • The article’s point about Django settings resonated: there’s interest in typed, validated configuration objects (e.g., dataclasses/Pydantic-like patterns).
  • Current pain: typos in settings keys silently fall back to defaults; plugins add their own unvalidated settings.
  • Patterns mentioned include .env + python-dotenv, environment-specific settings modules, and central validation analogous to schema validation libraries in TypeScript.

Project Setup, Tooling, and Testing

  • Several share personal “starter recipes”: using uv, custom user models by default, split settings (project vs environment), .env.example, and tools like ruff, pytest, pre-commit, GH workflows.
  • Django’s test DB support, pytest-django, and model-bakery are praised as a very pleasant TDD experience.
  • django-extensions/shell_plus and Django 5’s improved shell imports are highlighted as quality-of-life tooling.

Ecosystem Comparisons and Critiques

  • Positive comparisons against Flask+SQLAlchemy+React: Django often requires much less boilerplate for forms, admin, and CRUD.
  • Some think Django is overkill for trivial apps; others say its structure helps prevent “big ball of mud” monoliths only if you’re disciplined.
  • One strongly negative view calls Django buggy and poorly designed, criticizing its ORM (vs SQLAlchemy), templates (vs Jinja2), and routing, and arguing it locks you into bad decisions.
  • There’s also a desire for better typing in Django code and docs; missing annotations are seen as a source of subtle bugs.