Tailwind didn't invent utility classes. We've done this since the '90s.
> significantly easier to maintain
Disagree totally. Utility classes are good for rapid prototyping. But they clutter your code, mix semantics with presentation, and are a pain in the ass when it comes to code reuse. The cascade part of CSS is, believe it or not, actually useful for code reuse. Need to change a font deep in some nested component? Not a problem with CSS. Tailwind, you're fucked. You'll need to modify each component layer to pass down a class prop. Or do some ugly context hack.
* Tailwind doesn’t claim to have invented utility classes, nor even utility-first CSS architecture.
* HTML has always mixed semantics and presentation.
* It’s terrific for production applications because we don’t lovingly hand-craft each DOM node. Far from being an enemy of reuse, it enables refactoring at the point of HTML generation, and aligns particularly well with partials and view helper functions/objects.
* The cascade is still there; you’re not fucked. Not even if you’ve been suckered into using some react-like framework.
no, we really didn't. tho i'll agree that utility classes have been a thing for longer than tailwind/bootstrap/tachyons/pico/etc have existed
> mix semantics with presentation
there is nothing semantic about class names: nothing, zero, zilch - using IDs are even worse due to specificity, with none of the "semantic" benefit. focus on the correct top level wrappers
part of me wonders about the extent of what HN commenters actually do on the web regarding styles, or if they just slap together some homogenous web app or static site where its rather easy to not have a design team needing flexibility on every little thing.
case in point, our main "button" has about 15 different base variants (that *3 currently) depending on context, not counting the interaction states.
Okay so one huge difference between now and the late 90's is that we have several very popular ways to create "components" of HTML/JS/CSS. From react to liveview it's very popular. This is important because it's much easier to maintain.
We did back then too. In fact we had SSR. It often took the form of CGI, like PHP - which, hate the language all you want, it has a very sane and scalable model.
and bi-directional data flow was done in the form on long polling. this sounds very much like a get off my lawn argument rather than anything rooted in reality of the now.
I’m familiar with the pain point you’re describing. It’s not the cascade, it’s the ability to target a child element through a selector. (Which utility based approaches do away with)
But the thing is you can always do that if it’s needed. There’s no one forcing you to strictly adopt the utility pattern. It’s all just vanilla CSS at the end of the day. If a hybrid approach works best for your project then do that.
Personally I find the need for this to be quite rare, and there are actually some good arguments against writing too much specificity in to your css even if it’s more convenient up front.
Although Tailwind won't target those descendant elements for you, it doesn't block your ability to do so. We found that 95% of our CSS goes away, the remaining 5% is still there with complex selectors and/or CSS settings that aren't in Tailwind. That remaining small amount is far easier to deal with.
I also started out thinking the whole idea seemed backward. Now I think of it this way: it works extremely well in practice, even if in theory it won't.
Tailwind didn't invent utility classes. We've done this since the '90s.
> significantly easier to maintain
Disagree totally. Utility classes are good for rapid prototyping. But they clutter your code, mix semantics with presentation, and are a pain in the ass when it comes to code reuse. The cascade part of CSS is, believe it or not, actually useful for code reuse. Need to change a font deep in some nested component? Not a problem with CSS. Tailwind, you're fucked. You'll need to modify each component layer to pass down a class prop. Or do some ugly context hack.