What I love about Django

Original Article ↗ Hacker News Discussion ↗

Django emerges as a widely admired web framework for its stability, long-term backwards compatibility, powerful ORM, and batteries-included features like the admin interface and robust documentation. Commenters highlight how its “boring,” incremental evolution reduces rewrite churn and makes it well-suited for large, long-lived products, while still allowing escape hatches to raw SQL, alternative architectures, or external services. Critiques focus on the Active Record–style ORM (and its propensity for N+1 queries), async and performance limitations, deployment complexity compared to serverless stacks, and differing philosophies versus frameworks like Rails, FastAPI, and Phoenix.

Overall sentiment

  • Many commenters are very positive on Django: “well‑designed,” “boring in a good way,” and productive for small and large apps.
  • A recurring theme is long‑term stability: multi‑year and even multi‑decade projects upgraded across major versions with minimal breakage.

Core strengths called out

  • No dramatic changes: slow, careful evolution is highly valued compared to frameworks that force rewrites.
  • ORM + migrations: widely praised for power and flexibility; can express complex SQL and has raw‑SQL escape hatches.
  • Admin: often “sells” Django to clients and is reused as an internal back‑office or data inspector.
  • Flexibility: viewed as opinionated but not rigid; easy to override behavior, customize routing, use Jinja2, plug in other ORMs, or split responsibilities with other services (e.g., Rust APIs with Django for migrations/admin).
  • Ecosystem: DRF + OpenAPI + TS generators, django‑allauth, single‑file tools, and Rust frontends like django-bolt get shout‑outs.

Pain points & criticisms

  • ORM/ActiveRecord:
    • Critiques: encourages queries “everywhere,” easy N+1 issues, wide implicit loading, ActiveRecord pattern disliked by some; syntax like field__gte and stringly‑typed relations called ugly / fragile.
    • Defenses: N+1 can be handled with select_related / prefetch_related, upcoming fetch modes, and discipline. Some see complaints as “skill/fit” issues.
  • Architecture & app structure:
    • Concerns about spaghetti from cross‑app queries, huge models.py / views.py, and lack of clear service layers.
    • Others advocate explicit service/selector layers, signals for decoupling, and “star‑shaped” core/aggregator apps. Signals seen as powerful but risky due to hidden side effects.
  • Content Types: impressive but warned against for long‑term maintainability.

Rails comparisons & politics

  • Some prefer Django over Rails on technical grounds (less “Rails Way,” more flexible).
  • A side thread debates avoiding Rails due to its creator’s public views; others argue separating software from author politics or note inconsistency in selective boycotts.

Async, performance, deployment

  • Async story and high‑throughput performance are cited as weaker points; some move to Go or other stacks for that.
  • Deployment seen as harder than static frontends/microservices because Django needs a 24/7 server process.