I love how Django just keeps slowly improving at every release. 6.0 is especially cool, including lots of really useful new features. Who said dependable tech was dull - this is the way is should be done. Well done all who contribute.
Any code or blog written by Adam is worth spending some time on.
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.
I tried django-q and I thought it was pretty terrible. The worst was that I couldn't get it to stop retrying stuff that was broken. Sometimes you ship code that does something unexpected, and being able to stop something fast is critical imo.
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.
It's okay till it's not. Everyone I know who had Celery in production was looking for a substitution (custom or third-party) on a regular basis. Too many moving pieces and nuances (config × logic × backend), too many unresolved problems deep in its core (we've seen some ghosts you can't debug), too much of a codebase to understand or hack. At some point we were able to stabilize it (a bunch of magic tricks and patches) and froze every related piece; it worked well under pressure (thanks, RabbitMQ).
Because it’s a seducer. It does what you need to do and you two are happy together. So you shower more tasks on Celery and it becomes cold and non-responsive at random times.
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.
Celery is great and awful at the same time. In particular, because it is many Python folks' first introduction to distributed task processing and all the things that can go wrong with it. Not to mention, debugging can be a nightmare. Some examples:
- 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.
> your side effects (e.g. database writes) aren't idempotent
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
In my experience async job idempotency is implemented as upserts. Insert all job outputs on the first run. Do (mostly) nothing on subsequent runs. Maybe increment a counter or timestamp.
I'm of the opinion that django task apps should only support a single backend. For example, django-rq for redis only. There's too many differences in backends to make a good app that can handle multiple. That said, I've only used celery in production before, and I'm willing to change my mind.
Template partials look good, which is one of the key reasons frameworks like React are as good and popular as they are, because you can reuse small segments of code.
I do a check for `request.htmx` in my views and conditionally return a template partial as needed. This reduced my need for one-off view functions that were only returning partials for htmx. Works pretty well from my experience.
Partialdef inline is the real win. Lets you define parts of a page without needing to place them in another file. Reduces the mental overhead of imagining how the inclusion will look because it’s already there.
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.
It's just syntactic sugar, making life a bit easier for HTMX users (cf. "htmx was the main motivation for this feature").
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.
Yeah, but I was doing the same thing 10 years ago with include mixed with extends and blocks. I can just include a file inside a template or render it directly.
you're kinda right, {% partial ... %} vs {% include ... %} is not a big difference, but my mind was vaguely thinking that "includes" have often been seen as large templates, whereas partial have been after the component era with the idea of making small blocks. (my 2 cents)
Correct. Django 6.0 comes with a standardised API, with 2 testing backends (ImmediateBackend and DummyBackend). You need a third-party backend to store and execute tasks.
Given that Python tends to produce fewer hallucinations when generated by LLMs I wonder if former Django developers using AI tools are secretly having a blast right now.
I think another ace up Django's sleeve is that it has had a remarkable stable API for a long time with very few breaking changes, so almost all blogposts about Django that the LLM has gobbled up will still be mostly correct whether they are a year or a decade old.
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.
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 fit 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?)
I mean, it is sad. But unfortunately that is what happened with "master", "slave", "whitelist", and "blacklist". No reasonable person construed these as offensive or having any implications about the wider world. But there are people in our profession who are determined to take offense where none is given, and unfortunately they got their way.
Well, "slave" has a pretty direct main meaning of an oppressed person doing forced labor. The word "master" is much milder in this regard (compare "master's degree" and "slave's degree"). The word "nonce" in normal usage seems even more removed from any pejorative secondary meanings.
That didn't stop people from throwing a fit over master-slave terminology in software (having nothing to do with slavery), going so far as to rename long-standing development branch names, as well as put significant effort into removing such terms from the code itself and any documentation.
I love how Django just keeps slowly improving at every release. 6.0 is especially cool, including lots of really useful new features. Who said dependable tech was dull - this is the way is should be done. Well done all who contribute.
Any code or blog written by Adam is worth spending some time on.
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.
I've been using Celery for years. What is the major issues you have with it and how does Django Q2 help?
I also use Kafka on other tech stacks but that's another level completely and use case.
OP here, thanks for the praise!
Yeah, I mentioned Celery due to its popularity, no other reason ;)
You are a great writer - thanks for putting this together!
I’m currently stuck with the tech debt of Celery myself. I understand that! Does Django Tasks support async functions?
I tried django-q and I thought it was pretty terrible. The worst was that I couldn't get it to stop retrying stuff that was broken. Sometimes you ship code that does something unexpected, and being able to stop something fast is critical imo.
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.
Why is celery awful?
> The Many Problems with Celery:
— 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
django-q2: https://github.com/django-q2/django-q2
It's okay till it's not. Everyone I know who had Celery in production was looking for a substitution (custom or third-party) on a regular basis. Too many moving pieces and nuances (config × logic × backend), too many unresolved problems deep in its core (we've seen some ghosts you can't debug), too much of a codebase to understand or hack. At some point we were able to stabilize it (a bunch of magic tricks and patches) and froze every related piece; it worked well under pressure (thanks, RabbitMQ).
Because it’s a seducer. It does what you need to do and you two are happy together. So you shower more tasks on Celery and it becomes cold and non-responsive at random times.
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/
Celery is great and awful at the same time. In particular, because it is many Python folks' first introduction to distributed task processing and all the things that can go wrong with it. Not to mention, debugging can be a nightmare. Some examples:
- 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.
> your side effects (e.g. database writes) aren't idempotent
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
In my experience async job idempotency is implemented as upserts. Insert all job outputs on the first run. Do (mostly) nothing on subsequent runs. Maybe increment a counter or timestamp.
From your experience, what is a better alternative guys?
Not the comment that you replied to but I use my own Urd. It's a fancier Cron that you can stop fast. Which is imo what you normally want.
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.
There’s no alternative (while prototyping), and anything else is better (when you properly defined your case).
DjangoQ2 is a fine alternative during early development
Computer, load up Celery Man please.
I'm of the opinion that django task apps should only support a single backend. For example, django-rq for redis only. There's too many differences in backends to make a good app that can handle multiple. That said, I've only used celery in production before, and I'm willing to change my mind.
With that logic, the Django orm should only support one database.
Template partials look good, which is one of the key reasons frameworks like React are as good and popular as they are, because you can reuse small segments of code.
Key benefit for reusability and composability in React is IMHO that they don't use templates at all, but everything is a function.
Exactly. There are a few libraries to achieve a similar thing in Python:
* 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 most obvious value here is for HTMX, which requires a lot of partial templates.
React allows for encapsulation of state in a reusable component, its more than just templating.
They're a neat design. I started using them on my blog the other day as part of trying out Django 6: https://github.com/simonw/simonwillisonblog/blob/faec3532183...
Amazing that Django didn't have this until 2025
Wouldn’t Jinja2 macros count?
But you could already reuse templates in Django by including them. What am I missing?
Check out the HTMX example in the blog, this helped me better understand how it could be used
https://adamj.eu/tech/2025/12/03/django-whats-new-6.0/#rende...
I'm an avid HTMX user but never did I ever think "I'm using so many includes, I wish I didn't have to use include so much."
What I would like is a way to cut down the sprawl of urls and views.
I do a check for `request.htmx` in my views and conditionally return a template partial as needed. This reduced my need for one-off view functions that were only returning partials for htmx. Works pretty well from my experience.
Partialdef inline is the real win. Lets you define parts of a page without needing to place them in another file. Reduces the mental overhead of imagining how the inclusion will look because it’s already there.
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.
It's just syntactic sugar, making life a bit easier for HTMX users (cf. "htmx was the main motivation for this feature").
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.
indeed the vintage templating was a logical bottleneck
How is it different from include? Just less files from my perspective
The "inline partials" feature is neat, means you can use and define a partial at the same time.
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...
Yeah, but I was doing the same thing 10 years ago with include mixed with extends and blocks. I can just include a file inside a template or render it directly.
you're kinda right, {% partial ... %} vs {% include ... %} is not a big difference, but my mind was vaguely thinking that "includes" have often been seen as large templates, whereas partial have been after the component era with the idea of making small blocks. (my 2 cents)
I asked the same question
There've been a variety of open source attempts at this idea. Is this official one now the best to use, or are the others still compelling?
https://django-cotton.com/ is component-based. I used it a bit, it's nice if you're used to the ways of front-end frameworks, I guess.
https://github.com/django-components/django-components also looked interesting
While using Cotton my thoughts were "ok, it's kinda cool... but do I really need it ? No. Is it worth the extra dependency ? No."
There is something very appeasing in just pulling Django and have all the basics covered. It's nice to have options when needed though.
Template Partials and HTMX seems like the Django equivalent of View Components and Stimulus for Rails, which is nice.
Also, good to see first class support for Tasks, among a lot of other niceties!
If I understood correctly, to use Tasks in production right now you need to use this as well:
https://github.com/RealOrangeOne/django-tasks
Is that correct?
Correct. Django 6.0 comes with a standardised API, with 2 testing backends (ImmediateBackend and DummyBackend). You need a third-party backend to store and execute tasks.
More discussion: https://news.ycombinator.com/item?id=46153116
Given that Python tends to produce fewer hallucinations when generated by LLMs I wonder if former Django developers using AI tools are secretly having a blast right now.
I think another ace up Django's sleeve is that it has had a remarkable stable API for a long time with very few breaking changes, so almost all blogposts about Django that the LLM has gobbled up will still be mostly correct whether they are a year or a decade old.
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.
If Python produces less hallucinations it's not because of the syntax, it's because there's so much training data.
[flagged]
Well, https://en.wikipedia.org/wiki/Nonce_word
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 fit 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?)
> 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
I mean, it is sad. But unfortunately that is what happened with "master", "slave", "whitelist", and "blacklist". No reasonable person construed these as offensive or having any implications about the wider world. But there are people in our profession who are determined to take offense where none is given, and unfortunately they got their way.
Well, "slave" has a pretty direct main meaning of an oppressed person doing forced labor. The word "master" is much milder in this regard (compare "master's degree" and "slave's degree"). The word "nonce" in normal usage seems even more removed from any pejorative secondary meanings.
More to your point, yes, taking offense can be turned into a weapon: https://nassimtaleb.org/2016/08/intolerant-wins-dictatorship...
Amusing to have my throwaway comment replied to with links to earnest points from prominent essayists. Never change, hacker news!
We don't need to bring this kind of thing up. We're not school children and most of us are technology professionals, so the meaning is clear.
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. ... name collisions ... . They're too common to be interesting.
https://news.ycombinator.com/newsguidelines.html
American hegemony, and all that.
In the US they spell it as nonze.
No we don't.
Pretty positive that was a joke/bait…
It absolutely was a joke
Slightly absurdist non-sensical humour I’ll admit, but none the less, a joke :-)
https://en.wikipedia.org/wiki/Context
That didn't stop people from throwing a fit over master-slave terminology in software (having nothing to do with slavery), going so far as to rename long-standing development branch names, as well as put significant effort into removing such terms from the code itself and any documentation.