[SunboX]

I really don't see the benefit. Sure, you don't write "CSS", but you write a lot of classes that look like CSS. If you write class="bg-white no-underline" you could easily write style="background: white; text-decoration: none;" and every frontend guy will understand it. I don't get the point.

[mattferderer]

If this article didn't make it click for you, that's understandable. It took me a long time of hearing about this & thinking it was stupid before it made sense. When that happens to me, it's usually a sign of something good.

The author of Tailwind suggested I read his best effort at explaining why this makes sense.: https://adamwathan.me/css-utility-classes-and-separation-of-...

Towards the end of the article it started clicking for me.

[paulsutter]

Easier just to quote the reason he gives:

“With inline styles, there are no constraints on what values you choose... Utilities force you to choose...

You can't just pick any value want; you have to choose from a curated list. Instead of 380 text colors, you end up with 10 or 12.”

[ealhad]

And of course, those colors are fully customizable.

[jacamat]

in what way is that consistent tho?

[neurotrace]

In what way is it not? You'll consistently get 10 or 12 colors instead of getting an inconsistent set of colors, for example.

[jacamat]

But I only want the element to be the color it IS, not a range of colors it could be. Whats to stop a dev using $concrete when they should be using $cloud? or $linkGray instead of $headerLinkGray?

these inconsistencies compound, especially across teams.

[neurotrace]

Nothing would stop them from choosing to use cloud vs. link gray but it's far easier to identify and fix those cases than it is to have #CCC, lighten(#CCC, 10%), etc. around the codebase. This doesn't fix human error, just reduces it.

[akvadrako]

I admit, after the middle of that article anything would look good.

It's a good realisation that there is no real separation of semantics and styling between HTML and CSS. XSL would have been one solution, but it was just too XML-ly. Personally I found it a joy; I could design my pages with pure semantics alongside a turing-complete stylesheet.

However now we have web components - your HTML and CSS are tightly coupled, but scoped. And the semantic / styling separation is provided by the shadow DOM. So no need to create inner platforms like Tailwind.

[davidwparker]

Did you read the article? There's a header titled "why is this different from inline styles?" that addresses your specific question.