IMO Tailwind only really makes sense if you're using a component-based framework. Trying to adopt it in a vanilla Django app (with monolithic templates) will lead to lots of duplication.
Not who you replied to, but it's basically how tailwind works. The magic of tailwind comes from a few things:
EVERY property must be explicitly specified. There is no "cascading" (inheritance). At first glance, this might seem like a horrible idea, but it has a TREMENDOUS upside in that everything is explicitly defined in the clearest possible way. (the style is directly ON that exact element. if you have a div inside another div, that inner div will not inherit font, colors, etc. You must define it all again).
The benefit of this is that everything can be "componentized" or split apart, and reordered, and moved around, and nothing will "break" stylistically. Your styles literally are perfectly attached to the structure. This is because EVERY single element is decoupled from EVERY other element, stylistically. This is truly the 100% stark opposite of traditional CSS.
A good example of this... is the very first time I googled a tailwind component, for some dropdown or something, I pasted the HTML + CSS classes directly into my project in some arbitrary spot, refreshed, and it looked PERFECT. I was literally floored and stunned! If you have programmed wordpress or other sites back in the day, and you know the true nightmare of trying to put some arbitrary bit of css or some script into your own projects and the styles are all conflicting, thats what I'm talking about. You know that pain. Even my BEST projects back in the day where I SWEAR to myself "im going to make THIS project the perfect CSS structure", ... after about a month i would be once again caught in these complex awful webs of conflicting and overwriting classes, despite my very best efforts.
Now there are downsides to this as well, but they're mitigated by using a component framework:
First, Because everything must be explicitly defined in EVERY place, this obviously creates a lot of duplication. After all, this is the entire point of CSS classes. Lets say you have a shopping cart item in one area of the app, the main listing, and then you want to show it again in your shopping cart. Youd have to define those style classes twice using tailwind if youre using a standard app which has "layout files" and "views". Now a component based framework though means you can make a component called <ProductItem /> and define the classes ONCE in that component. In this sense, a component almost becomes a much more advanced replacement for a CSS class (in a sort of weird and twisted way).
Lets take it further, and say WITHIN the product item is some text that looks like this: "Reviews (5) [NEW]!" And its styled a certain way. Now lets say that same style text appears below a different type of "review" and not a product item. In this sense, you can't use <ProductItem />, but you could make a new component called <ItemMetaInfo /> and then write your class in there (once), and extract that out to a component. There is a sweet spot to extracting out components vs a slight amount of duplication (say...5%). This also aligns VERY nicely with the entire purpose of component based frameworks is that the complex logic lives within the component... so lets say your <ItemMetaInfo /> grows in complexity over time, maybe it shows literal star SVGs, or supports multiple A | B | C sections based on an input parameter. That complexity can live in that new component along with the tailwind classes, defined once.
The second downside is its a LOT of typing, and this is where tailwind really excels to me. The properties you type are a god send, and SO much faster, easier to remember, and everything. This is coming from a vim freak who has memorized and written thousands of hotkeys and macros over nearly 15 years for CSS, and 100's of projects over the years. With tailwind, you do NOT need editor completion or anything like that. Its SO fast that it feels "effortless" in terms of the "ugh" resistance from writing CSS.
Scroll down about 100px and watch the realtime demo of them adding css classes and watch the design change on the left. It really IS THAT FAST to write tailwind classes and design THAT quickly, including responsiveness, and everything. This is 1000% not the same as css even with the very best macro/autocomplete setup.
> everything is explicitly defined in the clearest possible way. (the style is directly ON that exact element. if you have a div inside another div, that inner div will not inherit font, colors, etc. You must define it all again).
Except this isn't the case if you ever touch any of the spacing[0] parts of tailwind. Then you'll suddenly have your elements growing margins out of nowhere, seemingly, and you once again have to look at the ancestry of an element to figure out why its being laid out the way it is.
Hey, yes, I know about space. There's also hover-group, etc.
Those seem to ignore the spirit of what I'm saying though, as firstly, no one says you have to use them if you truly want 100% decoupling. They're just convenience functions.
If you want to control margins based on component indexes and only use margin, then great.
Secondly, they're quite simple to understand.
They're also not out of nowhere, they're out of what you explicitly define as say, space-x-4. Having this be on the parent just makes great intuitive sense, that it wouldn't be defined on the individual items. If I see items evenly spaced I don't even have to think about it that it's obviously on the parent. The mental overhead of this is truly negligible.
I would argue that "spacing growing out of nowhere" is an order of magnitude more painful when using traditional CSS that has grown beyond the "perfect" starter phase of every complex app that uses normal CSS. And I've even tried using all the different CSS frameworks from back in the day where you write classes in certain ways with prefixes, etc etc. It is inevitable that eventually you get so much tangled and dead code, the mental overhead of that is now something orders of magnitude more.
While we are talking about that, you mentioned it being bloated. Your argument is that it takes "CPU" cycles... I forget the exact article (and exact details, paraphrasing), maybe it was github. Classes outperform inherited CSS tremendously, and I think it was github that tried to design their site using 10's of thousands of 1-level-deep classes instead of nested. This is just nitpicking, however. With tree shaking, I have an entire app that sees millions of visitors per month get a 3kb css file when gzipped. The bulk of the js (compiled html) takes up < 100kb for the entire app. I don't think even the most "lightweight" wordpress theme or what have you comes close to that. I just googled "most lightweight high performing wordpress themes" and some blog spam has most of them weighing in at 900kb-1mb (!!!).
I don't think it's inferior or superior, just a better approach for certain people.
Personally I've found Bulma to work well in conjunction with Django.