Comment by toastal | Hacker News Reader

Comment by toastal | Hacker News Reader

Parent Full thread

Utility classes are meant for utility purposes, not to replace CSS, but you see so many projects out in the wild now terrified to have a classname that’s relevant to the topic which makes it harder to organize, but also harder to select for userStyles, filter lists, etc. (i.e. if you make a FooWidget, add the .FooWidget class so real folks can read/parse thru the code easier for their needs …or just for their knowledge of what others are doing, and maybe actually put some styles on that bad boy instead of every property being behind a util). I have spoken with some engineers that only know how to speak Bootstrap or Tailwind, & not a lick of CSS. This isn’t just 2000s thinking to consider pumping the brakes a little as utilities at this point have definitely blown out into ‘overuse’ & ‘overreliance’, but these things come in cycles with a new idea taken to an extreme before we swing back to only semantic markup & selectors on element names again before the next pendulum swing. Even still, utilities aren’t a new idea, but just part of how reusable classes in CSS can just work – and rolling out with massive block of utility CSS that are mapped one-to-one with a single property is in the ‘smell’ territory.

Having X class strictly linked to X widget or component breaks down when your widget has multiple subcomponents which may or not be reusable, like having Y widget and Y widget with some slightly changed parameters. Suddenly your "clean" system isn't so clean and you end up either adding inline styles, extract these components into their own classes and naming them which just moves the complexity elsewhere, or creating your own frankenstein utility classes.

There' s reason why there was a rise in something like tailwind, because they ended up creating what IMO we end up doing anyway. For me, it's 100x easier to maintain to open a component up that is months old and grok every everything about it without having to reference some other CSS file or structure. If I want to tweak some aspect I can do so easily right there, I don't have to jump back and forth, and it's better than inline because I benefit from things like hover styles and responsive classes which I can't do inline. You can always extract truly reusable pieces into their own class.

Is it more verbose? Yes. Can it be abused? Yes. But I wouldn't go back to the "old" way and it isn't for lack of knowing how.

Criticizing utility-first libraries doesn’t imply that a) the only alternative is some component-based naming scheme nor b) that you can’t use pieces of both & definitely isn’t suggesting c) use inline style. I’ve used a mix of different system where appropriate for years now & it’s been a pretty good way to go. And you can still give the component a name even if you do mostly or all utility classes for your team & other users.

i'm just going by the example that you gave which is of a component based naming scheme.

just to be clear, perhaps we're talking about the same thing (mix of style) just from a different angle and more emphasis on one or the other. i still use a "global" stylesheet as a base but the majority of our work within components is utility classes, so i'm also not suggesting that everything be utility only.

Roger. I’m mainly saying jamming everything into a utility that is one prop per class is a mess. Mixing where appropriate is good.

If you know how to write tailwind, you know how to write CSS. The utility classes it provides are just a sort of shorthand form of CSS. With component based frameworks there isn't much of a need to define CSS classes in my opinion.

If you know CSS, you can write CSS. Sometimes utilities add indirection that’s harder to follow in the long term—especially with folks that aren’t already using these utilities. In 10 years, will it be easier to follow `mb-5` as medium border 5, middle box-shadow 10, margin block 5rem, min-block-size 10, mix-blend-mode 5, mild black version 5? If the utility has many properties tied to them (e.g. those softer shadows of layered box-shadow) named .stackedShadow--depth3 this sort of utility has earned its value that will be easy to understand why it exists vs. .pt-6 when an explicit value or CSS variable could have sufficed. This doesn’t apply to all cases, or all projects, but I would predict in 5 years the fad of pushing everything into a utility will be dead in favor of moderate usage.

Yes, I also agree that we should use inline styles for everything. The problem with CSS is the C. I don't want to come up with class names or put styles in a separate file or even a separate section in the same file (Vue). I want to look at the tag and immediately see how it's styled. No hidden or indirect styling whatsoever.

My CSP won’t be happy to include unsafe-inline. Inline styles are hard to override. Not overthinking but I try to put some consideration for the folks using userStyles for their accessibility.

Naming things is often hard, but at least with UI you’re usually building something concrete so there should be some name—if not a wrapper that holds more loose parts you can’t easily control (like a #Content element around some reStructuredText output).

The cascading part is a double-edged sword tho. It can be used to great effect for good, but it can be unweildy with a disparate or undisciplined team. But it’s often better to work with it rather than fight uphill against the only style engine we have in browsers (if feasible)—the output will generally be smaller & easier to follow with less to know or maintain.

Well I guess it’s already been 5 years since I’ve used tailwind and everyone still agrees that:

    mb-5 = margin-bottom: 5x (something)

There’s a use for utility css, it’s becoming standardised in a way, and I predict it will continue to be used and understood in another 5 years

Everyone? I wasn’t sure. I doubt a fresh-outta-CSS-bootcamp person would either.

It’s ‘standardized’ within its niche. Niches can have shorthands, but breaking into mainstream seems a bit lofty considering the ambiguity from the outside (I’ve never used regularly) as well as how much & how far you can get with CSS without a library (not saying there’s not obvious places for libraries).

You could be more clear by writing margin-bottom-5, but then you reinvented CSS. And using shorthands for singular properties feels like reinvented CSS—especially since the name implies you can’t even refactor mb-5 { margin-bottom: 6α }. If you can’t use it to refactor, what’s its point?

> Everyone? I wasn’t sure. I doubt a fresh-outta-CSS-bootcamp person would either.

You could say the same about any api not being immediately obvious.

> And using shorthands for singular properties feels like reinvented CSS

It’s quite a nice way to describe css in my experience. The shorthand classes actually teaches you css too. As they’re basically a 1-1 mapping, but you can write them much faster than manually writing the styles

It also scales well, as you don’t get crazy css class hierarchy’s that are hard to modify.

> you can’t even refactor mb-5 { margin-bottom: 6α }. If you can’t use it to refactor, what’s its point?

Not impossible, I mean you can easily edit the tailwind.config to be different for mb-5. Or search all relevant instances of mb-5 and replace them with mb-6 for example.

I think it’s best for component-driven development, where you want to encapsulate styles with components and not have them dependent on the context that their in. It does make the HTML more verbose, but development much easier and faster

In the last case, had you just used a CSS variable, you could just change that.

Reply on news.ycombinator.com