[zelphirkalt]

I for one do not understand what is so difficult about making a team internal decision about how some "component" (here in quotes, as I am actually thinking of an HTML subtree with specific purpose somewhere on an HTML page) is going to be named, and then give it that name as CSS class. Are people never talking with each other? Are people unable to grep a code base, before making up a new name? And how many similar but not same purpose things do you have on your pages, that this becomes a serious problem? Or is it just a discipline problem? People can name hundreds of useless OOP abstraction classes, but cannot be bothered to think of a good name for a "component" on a web page?

I mean, come on, there is usually tons of context and team internal language for the new thing to build and to talk about it, distinguishing it from the old thing that was already built.

And if that's too hard, then allow the design department to name the things they design and notify them about any clashes. They must have a design language anyway.

[9dev]

Again, this isn't really about difficulty—you can solve problems of arbitrary complexity by establishing a process, guidelines, rules, and documentation. But unless your goal is maximising the number of meetings you need to communicate arbitrary naming conventions, having a framework that takes these decisions from you is an efficiency boost. There will always be new invariants, combinations, or elements to style.

Say you have a .button class for clickable button elements. One day a junior engineer realises they need two of them next to each other, while one is more important. Predictably, as they don't want to bother one of the seniors with this, they are going to introduce a .secondary variant. A few days later, someone else gets tasked with introducing a variant prop for <div class="card">, so the upsell banner can be styled differently easily. "Oh!", they think, "Neat! there's a secondary class that sets all the same props I need!"—and just like that, coupling was introduced.

Sure, this is a contrived example. The junior could have scoped the class to buttons; or added an explanatory comment; or written a note to the team; or asked a senior; someone could have seen it in code review; or a heap of other mitigations. But all of these happen to fail sometimes, and compound over time. This isn't even really about CSS, but entropy at the end.

So to me, this is the benefit Tailwind brings to the table: By providing a styling language that doesn't require making up rules as you go, that scales to arbitrary project sizes, and most importantly doesn't need additional communication, you get optimized, side-effect free CSS that you will immediately be productive in, even as a new joiner or when you return after a long time.