Comment by giancarlostoro
13 hours ago
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.
13 hours ago
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.
1 reply →
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...
1 reply →
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
1 reply →