Tailwind made it possible for me (backend developer) to write somewhat maintainable frontend code. It’s a joy to use both as a writer and reader.
As a frontend developer I don’t like Tailwind for several reasons, it brings the styling into the structure. As a frontend developer Tailwind is at a forefront of what I would consider bad practice and encourages a code style which would be a nightmare for me to maintain.
That said. Tailwind seems to be loved be people who are not professional frontend developers. It seems to be just the right tool for people who are not necessarily proficient in CSS. And perhaps people like me (and the dead sibling) need to learn to let go and allow other people to have the tools which makes it easier for them to do the job which they are not experts at. For that reason I understand Tailwind, even though I don’t agree with it.
Show me a site that has CSS Zen garden style replaceable stylesheets that totally overhaul the nature of the site. It's incredibly rare and almost always not worth the effort. What business says "I want to overhaul the styles of my application but change no structure at all. I'd posit it's near 0.
Even if that's your goal, and I'd argue that it shouldn't be, you can still do that with TWCSS and the @apply keyword. You can write your generalized names then apply whatever twcss keywords you want to them separate from your document's structure.
If your overhaul amounts to changing a "theme" you can easily do that with twcss. In fact, that's basically the point.
I am a professional frontend developer and I love it.
I mean header files are OK, and professional C developers probably love them, but not having header files is kind of great too :)
I have a similar comment elsewhere in the thread but it applies here too, I think: the main drawback of Tailwind is that it's extremely general. I'd imagine a well abstracted, focused, domain-specific set of CSS created by experienced frontend developers will be much better within that domain.
Pair your tailwind with styled components and you can finally reach the dream of semantic HTML.
i prefer the later. with styling in structure if i make a change in one place, it effects the one thing i intended it to
with structure in styling, if i change one thing, it may impact many other things, some of which i might not intend to and are sometimes unknowable at the time of the change
If I change the structure I usually have to change the style anyway. And with component scoped styles, I know exactly where I need to do that (usually in the same file, or in a file referenced by the component).
As for shared styles I use the cascade which can penetrate the component boundaries, e.g. font-size, color, but usually --css-custom-properties.