I started a Python/Django position a year ago transitioning from PHP/Laravel and a number of frameworks there. I found Laravel’s blade components (and JS framework style frontend composition in general) very powerful and productive concepts for spinning up interfaces.
Fuelled by the lack of such a thing I wanted in the Django eco-system I built cotton alongside a project and now feel like it’s really helping me make light work of building capable and re-usable frontends in Django and would like to share it with the community.
Thanks, I’d like to provide more usecase examples. I noticed you’re familiar with htmx and that could be a good topic to cover. Using the ‘{{ attrs }}’ in a component will allow you create reusable inputs which you can easily pass down htmlx attributes to the base input element.
But my knowledge of htmx is fairly limited. I’d be interested to hear about your experience using cotton. Thanks for the first PR too
Love the concept I wonder if you tried some of the similar packages out there, and if so what’s your thoughts on how Cotton differs? See the list of template-related packages on awesome-django.
Personally I have mixed feelings about Cotton components using the same syntax as vanilla HTML custom elements. Feels like it’d make it harder to know what’s what? And could be problematic for any HTML linting.
Thank you, I researched a few and tried a couple at the start, from jinjax (requires jijnja templates and I found no documentation for setup with django) also django-components (a bit too heavyweight and I don’t require data component setup, just quick partial creation and reuse with slots and named slots.) I also wanted the ‘{{ attrs }}’ feature which helps a lot designing custom inputs.
About the syntax, I think quite the contrary, you don’t need any specific plugins in your IDE/editor as the tags are already xml-like so you get auto completion in full and self closing tags.
It’s certainly a paradigm shift for some but for those who have already built js frontends ala svelte, vue then it’s already familiar.
So far I’ve only really gone through the quick start so I haven’t tried using it with HTMX yet, but that’s something I’m interested in trying out. I think HTMX, Alpine (which I still need to learn) and Cotton could be a pretty cool combo.
One thing I’d like to try is using Cotton as a dependency in a separate third party application. Cotton has it’s own project level settings/configurations, so I think that would make it a little bit tricky for me to justify using it in my own 3rd party application, but I’ll try it out and see if I could make any suggestions to make that smoother.
I think some additional usecase examples and references would be great. I understand the docs site is brand new though, so no rush.
That’s such a cool project! Thanks for contributing.
I would like to have a go locally and also contribute, but haven’t found any instructions on how to “develop locally”.
I’ve been looking for something like this so thank you @wrabit for building it.
I’ve got a basic example working (a component) but am finding that tailwind changes don’t register, even when running a watcher. Has anyone else experienced this?
Hi Luco, thanks for the comment, I’ve got no experience in that package but when using base tailwind and specifying .html in your content setting in tailwind.conf.js it works just fine on my side.
I’m using a root level templates directory and had improperly configured tailwind.config.js so it wasn’t watching subdirectories of template - and hence any changes in the ‘cotton’ subdirectory.
This line fixed it: content: ["./templates/**/*.html"],
Github.com has met more complicated problems then many of us, and I think the https://viewcomponent.org/ is a promising solution for Django developers.
@michael-yin I think we already had this conversation on reddit but to say it again - This project was not inspired by the same pattern you refer to. It’s not intended to be a ‘server side component solution’. There is already django-components and others for that.
This project was built to add functionality similar to modern UI composition found in Vue, Svelte and Laravel’s anonymous blade components - which I find a very powerful concept allowing me to create UI’s very quickly and optimally re-use code thanks to the simplicity of some basic concepts:
slots
named slots
dynamic slots
attributes
props
and cotton does that well…
without needing to create a separate backend component
without needing to register a component
whilst enabling other possibilities normally restricted with django’s native tags
Think of cotton as crafting your UI with re-usable partials that are configurable. You will end up writing less code and improving DRY / maintainability. It’s not about backend components.
Django template provides enough capability to execute this concept just fine.
Let me first say that the library looks very nice, and I’d love to take a deeper dive and try it out (probably won’t happen for a while, unfortunately). And I can see it’s already taking off .
I’m a heavy user of django-components, among other stuff related to the topic I would say. So I really understand where @michael-yin is coming from.
Do you have any specific arguments against having an optional in-between .py component logic, or is it just your preference? On a first glance, I would chose Cotton syntax over django-components syntax, but I have too many use cases where I don’t want some component logic cluttering my templates or views.
This is by so far another exiting thing that i found in the django community. I’ve been recently having difficulties picking a ‘solution’ for this problem, there are some options there as I see, but still did not able to find a ‘ideal’ option. I saw about cotton today in the bytebugs Youtube video and come here by search. I will try out cotton and will come back with my ideas.
I wonder if you tried some of the similar packages out there, and if so what’s your thoughts on how Cotton differs? See the list of 
but to say it again - This project was not inspired by the same pattern you refer to. It’s not intended to be a ‘server side component solution’. There is already django-components and others for that.
.