Django: What’s New in 6.0
Key topics
The Django 6.0 update is generating buzz, particularly around its new "template partials" feature, which allows developers to reuse small code segments. While some commenters see this as a nod to React's reusability, others point out that React's strength lies in its ability to encapsulate state, not just templating. As developers weigh in, a nuanced discussion emerges, with some noting that template partials aren't drastically different from the existing "include" feature, while others appreciate the new feature's design and flexibility. The conversation highlights the evolving needs of developers and the ongoing quest for more efficient, modular coding practices.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
37m
Peak period
121
Day 1
Avg / period
42
Based on 126 loaded comments
Key moments
- 01Story posted
Dec 9, 2025 at 3:33 PM EST
24 days ago
Step 01 - 02First comment
Dec 9, 2025 at 4:10 PM EST
37m after posting
Step 02 - 03Peak activity
121 comments in Day 1
Hottest window of the conversation
Step 03 - 04Latest activity
Dec 19, 2025 at 7:54 AM EST
14 days ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Everyone just busts out "React" for every small thing, but few commit to actually learning this pretty complicated technology.
The last two recent Cloudflare outages were because of React.
The way you can render just a named partial from both the render() shortcut and the include tag is nice too:
https://docs.djangoproject.com/en/6.0/ref/templates/language...
https://adamj.eu/tech/2025/12/03/django-whats-new-6.0/#rende...
What I would like is a way to cut down the sprawl of urls and views.
I'm using Unpoly and I just render the whole page and let Unpoly swap the content according to the target selectors, so no need for this. Not much difference in perf if you dont generate gigantic pages with heavy header/footer.
The use case is mainly driven by htmx where you will have lots of these partials and the view code renders them as individual responses.
* https://htpy.dev/
* https://pypi.org/project/fast_html/
* https://fastht.ml/ (different to above, I think)
* https://github.com/volfpeter/fasthx
Probably others. I strongly prefer this to templating, but I find it makes dyed in the wool Django people squirm.
The downside is I find them hard to read.
I think the template approach isn't quite right and yet neither is the functional approach.
At the end of the day these are a type of tree structure; I think we could conjure a new mechanism that gets the best of most/both worlds.
To be honest my main problem with templates is they have to be one per file. In principle there's no difference between naming a new file and naming a function, but in practice it just sucks. It's a higher barrier so people are less likely to write smaller components, and refactoring support completely sucks. Even renaming a template is a massive pain whereas renaming a function with decent LSP support is easy.
JSX hits that perfect balance between readability while still being regular functions. Maybe something is possible with the new 3.13 template strings?
With template strings, the symbols in the HTML string a just like Python code. Static analysis tooling can step in and do things.
We have ambitions to start an interoperability movement in Python HTML, so htpy and tdom could agree on a common Node structure.
A jinja/django template has an implicit context but for nested functions you really have to pass that context down through every function call.
It inevitably ends up just a big dict blob.
You get some typing support in an IDE but nothing really for function parameters.
Maybe I am doing wrong?
https://htpy.dev/usage/#passing-data-with-context
There is something very appeasing in just pulling Django and have all the basics covered. It's nice to have options when needed though.
>Jinja2 can offer performance improvements, particularly when it comes to speed.
https://docs.djangoproject.com/en/6.0/topics/performance/#al...
It will be interesting to see how the tasks framework develops and expands. I am sad to see the great Django-Q2 lumped in with the awful Celery though.
And debugging is a pain in the ass. Most places I’ve been that have it, I’ve tried to sell them on adding Flower to give better insight and everyone thinks that’s a very good idea but there isn’t time because we need to debug these inscrutable Celery issues.
https://flower.readthedocs.io/en/latest/
- your function arguments aren't serializable - your side effects (e.g. database writes) aren't idempotent - discovering what backpressure is and that you need it - losing queued tasks during deployment / non-compatible code changes
There's also some stuff particular to celery's runtime model that makes it incredibly prone to memory leaks and other fun stuff.
Honestly, it's a great education.
Task queues are like email. It's what everyone is used to so people ask for more of it, but it's not actually good/the right tool.
What does idempotent mean in this context, or did you mean atomic/rollback on error?
I'm confused because how could a database write be idempotent in Django? Maybe if it introduced a version on each entity and used that for crdt on writes? But that'd be a significant performance impact, as it couldn't just be a single write anymore, instead they'd have to do it via multiple round trips
— https://steve.dignam.xyz/2023/05/20/many-problems-with-celer...
> The problems with (Python’s) Celery:
— https://docs.hatchet.run/blog/problems-with-celery
> Dramatiq motivation:
— https://dramatiq.io/motivation.html
Here are some alternatives:
Dramatiq: https://github.com/Bogdanp/dramatiq
RQ: https://github.com/rq/rq
Huey: https://github.com/coleifer/huey
Hatchet: https://github.com/hatchet-dev/hatchet
https://temporal.io/
https://docs.dbos.dev/
https://news.ycombinator.com/item?id=45797228
https://python-absurd-client.readthedocs.io/en/latest/quicks...
Yeah, I mentioned Celery due to its popularity, no other reason ;)
There are bugs and issues, but because so many people are using it, you’re rarely the first to stumble upon a problem. We processed double-digit millions of messages daily with Celery + RabbitMQ without major obstacles. Regardless of what people say, it should be your first go-to.
I often prefer designing around explicit queues and building workers/dispatchers. One queuing system I miss is the old Google App Engine one - you set up the queue, the URL it calls with the payload (in your own app), the rate it should use, and that's it.
Fundamentally I think the entire idea behind celery and django-q is mostly misguided. People normally actually need a good scheduler and a bring-your-own queue in tables that you poll. I wrote Urd to cover my use cases and it's been rock solid.
I also use Kafka on other tech stacks but that's another level completely and use case.
In that post: https://adamj.eu/tech/2025/12/03/django-whats-new-6.0/#conte...
Court case yesterday: https://www.bbc.co.uk/news/articles/c04vqldn42go
Wikipedia: https://en.wikipedia.org/wiki/Nonce
Slightly absurdist non-sensical humour I’ll admit, but none the less, a joke :-)
It makes me sad when a secondary meaning, which does not even overcome the main meaning in usage, becomes an obstacle for the normal use of a word. It's like seeing a rainbow as a sexualized symbol not not for children, because it also happens to be used by LGBTQ+ community. (BTW, since you're a Brit: did people stop using the word "fag" to refer to a cigarette?)
Yes, seems so. I've not heard that in at least a decade
These guidelines are relevant here:
Eschew flamebait. Avoid generic tangents. Omit internet tropes.
Please don't pick the most provocative thing in an article or post to complain about in the thread. Find something interesting to respond to instead.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html
Also, good to see first class support for Tasks, among a lot of other niceties!
https://github.com/RealOrangeOne/django-tasks
Is that correct?
Has there been discussion about adopting/embedding django-tasks into Django 6.x?
https://guides.rubyonrails.org/layouts_and_rendering.html#pa...
I get remarkably good and correct LLM output for Django projects compared to what I get in project with more fast moving and frequently API breaking frameworks.
Probably the wrong time or place but I am also on the market literally as of yesterday so if anyone is looking for an experienced Django guy, I'm your man! oldspiceap@gmail.com
I am not roasting it or anything, go Django, but just an observation.
Not just the Framework -> Core migration itself, but the power to make breaking changes went to their heads, and they started quickly tearing up everything only to change their minds again, such as a short-lived "project.json" syntax.
Django is exactly the technology I'd pick if I wasn't already super familiar with the .NET stack. It's got the "batteries included" feel without the chaotic confusion of a million ways to do things. It doesn't have the breaking changes churn that happens elsewhere too.
Nothing wrong with that. One had to start somewhere.
[0] https://github.com/oca/queue