Hacker News Reader

Comment by SunboX | Hacker News Reader

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.

View on HN

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.

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

And of course, those colors are fully customizable.

in what way is that consistent tho?

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

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.

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.

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.

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

Reply on news.ycombinator.com