> I still don’t understand what it brings over putting style= whatever on the element.

You can't put a style for dark mode and one for light mode. Lifting these properties from styles to classes allows you to combine them with media queries and states.

Sounded to me like parent commenter was not advocating for that sort of thing so much.

They said

> Like imagine your company’s main “button” element. It’s got 8 different sizes, optional icons on both sides, animations, styles, each needing to support different color combos. Tailwind is miserable for that. You get giant huge balls of spaghetti classes all over your button, and it’s pretty incomprehensible.

Which to me sounds like they would not use Tailwind for dark mode / light mode things either. But I might be misunderstanding

It sounds like you're saying we need to consider the flexibility and articulation that classes enable when they reflect considerations beyond concrete presentation.

I just today, I helped to a junior that asked me how he can move a button on a toolbar. He was fighting against some legacy webapp made with JSPs, that have a f** zillon of style="XXX" stuff on nearly everything. And what is worst ... nearly everything using "position: absolute" to layout nearly everything.

Try to maintain that horrent webapp.

PD: That webapp it's what a ex co-worker called "technical bankrupt"