> I don’t see how that’s an argument for CSS “being advanced enough”
That's a separate argument.
I hear mostly two justifications for tailwind:
1. It is (or used to be) hard to do things in CSS like variables, calculated properties, themes, scoped rules / namespacing. (Pre/Post) Processors are going to be required anyway, so we might as well use Tailwind
2. It gives frontend developers and designers a common language (the utility classes) which makes it easier to establish workflows.
My argument for (1) is that CSS already supports a lot of things that used to require processors, and (2) could be achieved with a simple "library" that could just be imported directly.
I agree neither of those seem like good reasons to pick tailwind.
My take is that it removes needless indirection in any codebase that already has “components” - react/vue/solid/etc, template partials, functions that return html strings, whatever. See comment here: https://news.ycombinator.com/item?id=42804831
For that reason, plus it’s concision, I find it more productive use of time compared to css-in-separate-file.
If you don’t have components for separating semantics from presentation, then tailwind is less a good fit.
That's a separate argument.
I hear mostly two justifications for tailwind:
1. It is (or used to be) hard to do things in CSS like variables, calculated properties, themes, scoped rules / namespacing. (Pre/Post) Processors are going to be required anyway, so we might as well use Tailwind
2. It gives frontend developers and designers a common language (the utility classes) which makes it easier to establish workflows.
My argument for (1) is that CSS already supports a lot of things that used to require processors, and (2) could be achieved with a simple "library" that could just be imported directly.