Django: what’s new in 6.0

Template partials, includes & components

• Many welcome template partials as long-missing ergonomics, especially for small reusable fragments.
• Others note Django already had include and custom tags; partials are seen as a nicer design and syntactic sugar for a subset of existing patterns.
• Key benefits called out: inline partialdef, rendering named partials directly, and keeping related fragments in one file, which reduces mental overhead.
• Some compare this to Rails partials and to component systems in React/View Components/Stimulus, but stress React also encapsulates state and is more than templating. React is described as powerful but complex, with many pitfalls.

Templating vs function-based HTML rendering

• Several commenters prefer “everything is a function” approaches (htpy, fast_html, fasthx, component libraries), citing better composability, refactoring, fewer typos, and alignment with JSX.
• Downsides: these can be harder to read, require explicit context threading, and often devolve into large dict-like parameter blobs.
• Some Django component libraries (Cotton, django-components, iommi, compone) are seen as nice but not always worth extra dependencies when Django now ships reasonable basics.

HTMX and partials

• HTMX is repeatedly cited as the main driver: many small fragments, rendered in isolation.
• Inline partials are valued for HTMX-heavy pages, avoiding file sprawl.
• Others simply check request.htmx in views or render full pages and let tools like Unpoly swap targeted DOM, avoiding many separate partials.

Tasks framework & background jobs (Celery, etc.)

• There’s enthusiasm for Django’s standardized tasks API, but it currently needs third‑party backends (e.g., django-tasks), which serves as a reference implementation.
• Debate on whether this makes Celery/Django-Q2 obsolete; consensus is “not yet” and “depends on needs”.
• Celery is described as both indispensable and painful: easy start, then hard-to-debug failures, memory issues, serialization problems, and tricky idempotency.
• Others report Celery working reliably at scale and recommend it as the default due to maturity and community knowledge.
• Many alternatives are listed (Django-Q2, RQ, Dramatiq, Huey, Hatchet, Temporal, DB-backed schedulers), with a theme that simple DB+cron-style schedulers often fit better than full-blown queues.
• Multiple comments explain idempotent background jobs (safe to rerun) via upserts and checks, and note even stronger systems like Temporal still require idempotent activity logic.

ORM, migrations & multi-database realities

• One practitioner highlights pain when Django is a minor consumer of large, shared databases: Django’s “models define schema” assumption clashes with external tools and manual changes.
• Suggestions include: using Django’s multi-DB features, writing raw SQL where appropriate, introducing DB views/materialized views wired into migrations, or layering SQLAlchemy (e.g., via Aldjemy) for complex queries.
• Some criticize Django migrations’ reliance on inferring DB state from the live database, preferring frameworks where migrations are explicit DB operations and models sit on top.

Django stability, AI, and “heaviness”

• Strong appreciation for Django’s conservative evolution, minimal breaking changes, and “batteries included, one right way” ethos.
• This long-term API stability is said to make Django a sweet spot for LLM-based coding assistance; people report much better AI output on Django projects than on faster‑churning stacks.
• A few find Django “heavy” but still best-in-class for greenfield apps with control over the schema.

Meta: terminology tangents

• A brief side discussion arises around loaded terms like “nonce”, “master/slave”, “whitelist/blacklist”, and shifting language norms.
• Other participants push back, arguing such tangents are off-topic and contrary to HN guidelines about avoiding flamebait and name-collision complaints.