Hacker News Reader

Comment by badestrand | Hacker News Reader

Yes, the problem is that this library just replaced typing

    <div style="background: white">

with

    <div class="bg-white">

without realizing that the first is considered a bad practice for a reason and that the second is equivalent.

View on HN

Isn't that basically the same thing as inline styles?

Not quite, for a few reasons:

Inline styles don't respect media queries, which basically rules out responsive design

Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue)

Inline styles cause specificity issues, since they trump separate stylesheets.

Inline styles don't support print-specific styles.

Inline styles can't address pseudo-elements (such as ::before and ::after)

Inline styles can't apply to multiple elements. Utility classes can define .bg-blue once and have it apply to many things, which leads to shorter markup and quicker rendering speed.

Inline styles are a pain to type. Compare class="f-sm bg-blue" to style="font-size: 10px; background-color: #0000ff;".

Utility classes fix all of these things.

from https://www.mikecr.it/ramblings/functional-css/

Well summarized! Uitility/Functional CSS > Inline Styles

So what happens when your design changes and suddenly all your white buttons need to be off-grey? You change the class on 700 components?

In my experience design revamps of this magnitude has always needed fresh markup, CSS, Javascript - aka an entirely new front-end. But in case it is just the color of all buttons, then you'd change them in the components. 700 components is quite a stretch - for example there are at most 50 components in Morning Star's design system - http://designsystem.morningstar.com/.

But let's say there are 700 components, what's the alternative if we were using BEM? You'd have to change all the 700 CSS classes, breaking things everywhere thanks to cascades, inheritance, multiple selectors, and specificity. With Functional CSS, all you have to do is go to the markup, and change "bg-white" to "bg-offgrey", and nothing breaks.

In tailwind, you have a config file. You can just change the variable in the config file to the colour you need to change it to and it changes globally.

"white-bg" then becomes a blue background that's called white...

To be fair, you can do that with SASS variables too and is not unique to Tailwind.

I've not seen people encouraging variables called $white, because that's pretty short sighted. It seems to be encourages with utility css

That’s incorrect. What your missing is that in the config file you define a new color; say ‘rose’ and then the framework auto provides bg-rose, text-rose, border-rose, cutting duplication and bringing consistency.

I think the big shift started to happen when people started to say, let’s treat CSS like code and what would we expect of good code, and then all of these CSS Sacred Cows were then seen in a new light. The biggest of them all for me was ‘naming things are hard’, traditional CSS implies naming your classes is easy, and for a once off example it is always easy, but that approach is a lifetime commmitmnet to generating names on names just to add styles and this adds a naming things complexity burden that until recently has just been a generally unacknowleged invisible cost.

In my (limited) experience when I'm repeating the same set of classes over and over again I extract to a named component; You shouldn't have 700 identical buttons that all specify the classes that compose their look. 5-7 times = a use pattern and time to extract it.

https://tailwindcss.com/docs/examples/buttons

There seems to be a misconception that you need to go all-in on utilities when using a framework like Tailwind.

If you have 500 buttons using the exact same set of classes, you should of had a button class in the first place. Almost all my projects have their own button and form input classes for this exact reason!

Where utility-based CSS frameworks really start to shine is the other 75% of your codebase, where you're inventing clever class names, only to end up using them once.

This is also why Tailwind calls itself a utility-FIRST framework. Build things with utilities, and extract components to classes when the need arises. Avoiding early abstractions provides a lot of value (in any programming language for that matter). Not having to invent a name for every single piece of UI also saves a ton of headaches down the road.

That does make a lot more sense!

Ok maybe I was too negative too quickly, sorry. After reading another article [1] linked in some other comment I can see the appeal, if used with some templating engine that allows reusing html (like Vue or React).

It is crazy how new technology brings up old patterns again. Similar to how it was frowned upon to have JS near your HTML ("must be separated!") and now with React they are intertwined to a maximum.

I oftentimes find css to be the most complex and hardest to change part of web applications and am thankful to any approach that explores alternatives!

[1] https://adamwathan.me/css-utility-classes-and-separation-of-...

Reply on news.ycombinator.com