[timr]

> That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt?

Of course. It's obviously better to have 10,000 different names that are all loosely, but not exactly the same as the CSS property they're trying to represent.

[Timon3]

It undoubtedly is! I'd much rather learn 10,000 different names that follow a clear naming scheme and stay consistent between different projects and teams, than 1,000 different names that aren't guaranteed to have clear names or any consistency (even inside a single team).

But I'd also like to push back on the "10,000 different names" - the overwhelming majority of those names are merely variations of the value they assign, so using any class teaches you dozens to hundreds of those 10,000 names. So realistically, the comparison is closer to "1,000 project-specific and potentially inconsistent names" vs. "1,000 consistent names valid in any project using TW".

[array_key_first]

Those 10,000 names are already written, though.

Tailwind doesn't solve technical problems really, it solves social ones. In a perfect world we all write vanilla CSS. But, in my experience, it becomes extremely messy and hard to reason about in huge codebases with lots of developers. Which sucks but isn't surprising to me.