3 ms·
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
by giancarlostoro 11mo 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.
- squidsoup 11mo agoReact allows for encapsulation of state in a reusable component, its more than just templating.
- renegade-otter 11mo agoReact also requires you to know the long list of do's and dont's and is littered with minefields that most average developers are not even aware of. 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.
- Iwan-Zotow 11mo agoReally?
- agumonkey 11mo agoindeed the vintage templating was a logical bottleneck
- f311a 11mo agoHow is it different from include? Just less files from my perspective
- chistev 11mo agoI asked the same question
- simonw 11mo agoThe "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/#template-partials https://docs.djangoproject.com/en/6.0/ref/templates/language...
- f311a 11mo agoYeah, 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.
- agumonkey 11mo agoyou'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)
- simonw 11mo agoThey'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/faec3532183e993a5d143642225de045139b23a9/templates/includes/blog_mixed_list.html#L32-L59 https://github.com/simonw/simonwillisonblog/blob/faec3532183...
- chistev 11mo agoBut you could already reuse templates in Django by including them. What am I missing?
- teagee 11mo agoCheck 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/#render-partials-in-isolation https://adamj.eu/tech/2025/12/03/django-whats-new-6.0/#rende...
- The_Fox 11mo agoI'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.
- adparadox 11mo agoI 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.
- WD-42 11mo agoPartialdef 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.
- JodieBenitez 11mo agoIt'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.
- littlecranky67 11mo agoKey benefit for reusability and composability in React is IMHO that they don't use templates at all, but everything is a function.
- globular-toast 11mo agoExactly. There are a few libraries to achieve a similar thing in Python: * https://htpy.dev/ https://htpy.dev/ * https://pypi.org/project/fast_html/ https://pypi.org/project/fast_html/ * https://fastht.ml/ https://fastht.ml/ (different to above, I think) * https://github.com/volfpeter/fasthx 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.
- Induane 11mo agoThere are a lot of cool things about these, one that they are less typo prone and also they are often much faster. 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.
- globular-toast 11mo agoYeah, I agree, I find them hard to read. JSX is the best thing I've used. Elsewhere in the thread someone mentioned Cotton which seems to strike a different balance. 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?
- 11mo ago
- wahnfrieden 11mo agoThere'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?
- JodieBenitez 11mo agohttps://django-cotton.com/ 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.
- wahnfrieden 11mo agohttps://github.com/django-components/django-components https://github.com/django-components/django-components also looked interesting
- JodieBenitez 11mo agoWhile 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.
- apothegm 11mo agoThe most obvious value here is for HTMX, which requires a lot of partial templates.
- pier25 11mo agoAmazing that Django didn't have this until 2025
- Hamuko 11mo agoWouldn’t Jinja2 macros count?
- sgt 11mo agoI stayed away from Jinja2 ... was under the impression it has lower performance. But I could have been wrong all these years.
- Hamuko 11mo ago>For nearly all cases, Django’s built-in template language is perfectly adequate. However, if the bottlenecks in your Django project seem to lie in the template system and you have exhausted other opportunities to remedy this, a third-party alternative may be the answer. >Jinja2 can offer performance improvements, particularly when it comes to speed. https://docs.djangoproject.com/en/6.0/topics/performance/#alternatives-to-django-s-template-language https://docs.djangoproject.com/en/6.0/topics/performance/#al...
- simonw 11mo agoIt's had includes and custom template tags for over a decade. Partials are a slightly nicer design for a subset of that pattern.