> You can style stuff quickly and consistently right from the markdown, you don’t have to think of classnames for every teeny little thing, and you can somewhat imagine what stuff looks like just by looking at the jsx.

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

> 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"

> 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.

.brand-btn {}

.brand-btn--inverted {}

.brand-btn--icon-right {}

.brand-btn--smaln {}

.brand-btn--smaller {}

.brand-btn--big {}

<button class="brand-btn brand-btn--icon-right brand-btn--small brand-btn--inverted" />

However, very rarely need too many combinations of the same button with a brand logo.

We don't develop without components anymore.

You can have a nice component with all the cases, type-safe, and apply few utility classes to produce more maintainable code.

If you got lots of "custom" styling for elements, why can't one write a CSS class just as easily and give the element that class? Why is Tailwind better? Am I not also writing the definitions in Tailwind then and assigning those classes to my element then? I don't get what the benefit is supposed to be.

That’s exactly what I do for elements with lots of custom styling!

I guess I didn’t explain fully, but for things like the button example, I use regular ol css modules. Tailwind is for all the glue. And in my experience, most of the css you write when working on a feature is glue.