5 ms·

Do you treat your JS and TS the same way, eschewing semantic clarity?

troupo 1y ago
Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.
- skydhash 1y ago
  So you can name a component, but you cannot name the styles attached to that component?
  - 9dev 1y ago
    It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app. It’s not about not being able to name all these things, it’s that it’s pointless to do so.
    - jaggederest 1y ago
      You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.
    - skydhash 1y ago
      Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components. My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
      - 9dev 1y ago
        > If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less. > Tailwind [is] a path to ruin. Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat. For me, styling on the web is solved.
        skydhash 1y ago
        I get your point, but isn't this contingent on the colors and other properties being stable? I don't see why this can't be achieved with pure CSS instead of adding a (big) set of names as a layer of abstraction and then optionally pruning the build for performance. Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. > style bundling an issue unheard of But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
        troupo 1y ago
        > Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
        1y ago
  - troupo 1y ago
    Because you honestly don't need to, and shouldn't need to. CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years. What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952 https://x.com/simonswiss/status/1664736786671869952 Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/ https://piccalil.li/blog/cube-css/
    - skydhash 1y ago
      What I’m arguing about is that composition isn’t necessary in most cases. Because all components evolve independently. Also nesting is syntactic sugar, nice, but orthogonal to these discussions. And scoping is done with selectors. CSS isn’t an imperative language. It’s a declarative one. And what’s most important is understanding what it is trying to solve (mostly not styling elements with tag’s style). Which is what Tailwind is replicating. Tailwind may help you in some cases, but not because of a defect in CSS. It’s like using an ORM, then past a certain treshold, you find yourself doing (badly) SQL but in $language.
      - troupo 1y ago
        > Also nesting is syntactic sugar, nice, but orthogonal to these discussions. What is it with you and nesting? We were talking about scoping styles to a component. > CSS isn’t an imperative language. It’s a declarative one. So what? Doesn't mean you can't provide nice declarative ways of doing things. Like SASS has provided for 20+ years. > Which is what Tailwind is replicating. I fail to see the logic or, indeed, the meaning of your assertion.
        skydhash 1y ago

Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.

skydhash 1y ago
So you can name a component, but you cannot name the styles attached to that component?
- 9dev 1y ago
  It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app. It’s not about not being able to name all these things, it’s that it’s pointless to do so.
  - jaggederest 1y ago
    You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.
  - skydhash 1y ago
    Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components. My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
    - 9dev 1y ago
      > If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less. > Tailwind [is] a path to ruin. Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat. For me, styling on the web is solved.
      - skydhash 1y ago
        I get your point, but isn't this contingent on the colors and other properties being stable? I don't see why this can't be achieved with pure CSS instead of adding a (big) set of names as a layer of abstraction and then optionally pruning the build for performance. Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. > style bundling an issue unheard of But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
        troupo 1y ago
        > Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
        1y ago
- troupo 1y ago
  Because you honestly don't need to, and shouldn't need to. CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years. What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952 https://x.com/simonswiss/status/1664736786671869952 Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/ https://piccalil.li/blog/cube-css/
  - skydhash 1y ago
    What I’m arguing about is that composition isn’t necessary in most cases. Because all components evolve independently. Also nesting is syntactic sugar, nice, but orthogonal to these discussions. And scoping is done with selectors. CSS isn’t an imperative language. It’s a declarative one. And what’s most important is understanding what it is trying to solve (mostly not styling elements with tag’s style). Which is what Tailwind is replicating. Tailwind may help you in some cases, but not because of a defect in CSS. It’s like using an ORM, then past a certain treshold, you find yourself doing (badly) SQL but in $language.
    - troupo 1y ago
      > Also nesting is syntactic sugar, nice, but orthogonal to these discussions. What is it with you and nesting? We were talking about scoping styles to a component. > CSS isn’t an imperative language. It’s a declarative one. So what? Doesn't mean you can't provide nice declarative ways of doing things. Like SASS has provided for 20+ years. > Which is what Tailwind is replicating. I fail to see the logic or, indeed, the meaning of your assertion.
      - skydhash 1y ago