[snowcode]

Is this really an argument for Tailwind though? isn't this just an observation that both approaches seem to converge when the systems get very large and complex? At which time the work and effort is the same, except ..in the case of Tailwind you're using a made up syntax, and when writing similar amounts of code using CSS you can do it using the CSS standard. The key difference is that you would have to hope that Tailwind outlives CSS as a standard in terms of tooling and language support and continuing improvements (evolution) over time.

[MrJohz]

Definitely, Tailwind is just one approach to solving this problem, there are plenty of others. That said, one of the big advantages of Tailwind over other approaches, at least in my experience, is that it is far less bound to typical JS workflows, which means if you want to write HTML with your own favourite templating language, you can just drop in the Tailwind CLI and still get a lot of mileage out of the system. Compare that to CSS-in-JS or CSS modules, which are both very specific to the Javascript ecosystem.

The other big option is just using a methodology like BEM and being consistent with that, which in fairness also isn't bound to Javascript and has the benefit that - like you say - you're writing CSS as opposed to a DSL that is mostly equivalent to CSS. For me, the problems there come from the lack of tooling for writing really maintainable CSS - stuff like scoping and detecting whether a class is still in use. But it's definitely still an alternative, especially with some of the new features like nested selected that are coming out now.