4 ms·

> it's the future of writing CSS. Tailwind didn't invent utility classes. We've done this since the '90s. > significantly easier to maintain Disagree totally

> it's the future of writing CSS. 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.

krainboltgreene 4y ago
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.
- junon 4y ago
  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.
  - jozzy-james 4y ago
    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.
    - lenkite 4y ago
      Long polling has turned into SSE. And rocks with HTTP/2. What was once old is new and in vogue again!
      - jozzy-james 4y ago
        SSE isn't bi-directional, but sure - solves a bit of the long polling issue.
  - krainboltgreene 4y ago
    It absolutely was not popular.
    - junon 4y ago
      What was not popular? PHP? Because that's... well, patently wrong.
      - krainboltgreene 4y ago
        No, componentized HTML.
inopinatus 4y ago
* 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.
jozzy-james 4y ago
> We've done this since the '90s. 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.
deleted 4y ago
[deleted]
s__s 4y ago
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.
- kylecordes 4y ago
  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.

krainboltgreene 4y ago

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.

junon 4y ago
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.
- jozzy-james 4y ago
  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.
  - lenkite 4y ago
    Long polling has turned into SSE. And rocks with HTTP/2. What was once old is new and in vogue again!
    - jozzy-james 4y ago
      SSE isn't bi-directional, but sure - solves a bit of the long polling issue.
- krainboltgreene 4y ago
  It absolutely was not popular.
  - junon 4y ago
    What was not popular? PHP? Because that's... well, patently wrong.
    - krainboltgreene 4y ago
      No, componentized HTML.

inopinatus 4y ago

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

jozzy-james 4y ago

> We've done this since the '90s. 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.

deleted 4y ago

[deleted]

s__s 4y ago

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.

kylecordes 4y ago
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.