5 ms·

I think the divide here is whether or not your stack includes the concept of components. I think it's perfectly maintainable to write `class="rounded button ho

I think the divide here is whether or not your stack includes the concept of components. I think it's perfectly maintainable to write `class="rounded button hover:bg-color-black-700 bg-color-black-400 active:bg-color-black-500 focus:bg-color-black-500 rounded-sm text-sm text-color-gray-300"` because I only write it once, in my Button component. Then everywhere else, I just write `<Button>Inner Text</Button>`. The key difference is when I want to change how my site's Buttons look or behave, I only have to look in the `button.ex` file, instead of tracking down the relevant button classes in a mess of CSS files. Tailwind is not a good solution if you're writing something for CSS Zen Garden or a my_blog.html type website. Of course the repetition will render it an unreadable mess. But it is a wonderful solution when you have a framework generating the HTML for you.

lawn 3y ago
> because I only write it once, in my Button component. Unless of course you have several similar buttons with only minor differences between them. Maybe copy-paste? And then you have to slightly tweak your buttons... Or add conditional effects or dark mode and the complexity explodes, just on a simple button.
- MrJohz 3y ago
  The same is true of CSS classes, though - there you have the same choice between reuse and duplication. Do you have .button-primary, .button-secondary, etc, or do you use modifiers instead? The combinatorial complexity is inherent in the design of these sorts of components, you won't get away from it just by using a different tool to write your styles.
  - lawn 3y ago
    But CSS handles it much better, which is the point. You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary"). With Tailwind everything is duplicated, but with CSS you can move out the common parts.
    - 5Qn8mNbc2FNCiVV 3y ago
      Nothing holding you back doing exactly the same with Tailwind.
      - lawn 3y ago
        Of course, the solution to Tailwind's problem is to refactor it with CSS classes...
    - pcthrowaway 3y ago
      And to do this with a component framework and tailwind you give your <Button> component some props that customize it. With CSS you also have to worry about the cascade way too much, so while you are doing much of the same work with Tailwind, you get the nice benefit of inlining the styles which will actually apply to your component. Yes, you still have to think about organization and how to make different styles apply to variants of the main class, but it's so much easier to not also have to worry about how cascading rules might apply and constantly check different rules for specificity and overrides
      - tisc 3y ago
        I am curious what you - and with you more proponents of Tailwind in this thread - mean with “component” and “component framework”? I’m also Zen-garden age and with my very limited React experience this does sound like you are meaning a component framework like React, correct? If so; what would be the motivation for using JavaScript to style a button? Call me old - my coworkers do -, but that feels counterintuitive. Please note that I haven’t really formed an opinion on Tailwind yet. This is an honest question.
        MrJohz 3y ago
        Component in this sense is typically just "a composable unit of UI". That often corresponds well with JS frameworks that want to be able to attach state and behaviour to those units, but you can have components without needing Javascript. For example, partials in classic server-side rendering libraries can be thought of as components, although they tend not be used at such small scales. In CSS patterns like BEM, the B ("Block") is in many ways a component with different sub-elements and states. This is partly why Tailwind provides the @apply directive - it allows you to create "CSS only" components even if you don't have other ways of creating components. That said, other forms of components are often easier to use, and if you already are using them, Tailwind recommends using them for style reuse rather than @apply.
  - snowcode 3y ago
    Is this really an argument for Tailwind though? isn't this just an observation that both approaches seem to converge when the systems get very large and complex? At which time the work and effort is the same, except ..in the case of Tailwind you're using a made up syntax, and when writing similar amounts of code using CSS you can do it using the CSS standard. The key difference is that you would have to hope that Tailwind outlives CSS as a standard in terms of tooling and language support and continuing improvements (evolution) over time.
    - MrJohz 3y ago
      Definitely, Tailwind is just one approach to solving this problem, there are plenty of others. That said, one of the big advantages of Tailwind over other approaches, at least in my experience, is that it is far less bound to typical JS workflows, which means if you want to write HTML with your own favourite templating language, you can just drop in the Tailwind CLI and still get a lot of mileage out of the system. Compare that to CSS-in-JS or CSS modules, which are both very specific to the Javascript ecosystem. The other big option is just using a methodology like BEM and being consistent with that, which in fairness also isn't bound to Javascript and has the benefit that - like you say - you're writing CSS as opposed to a DSL that is mostly equivalent to CSS. For me, the problems there come from the lack of tooling for writing really maintainable CSS - stuff like scoping and detecting whether a class is still in use. But it's definitely still an alternative, especially with some of the new features like nested selected that are coming out now.

lawn 3y ago

> because I only write it once, in my Button component. Unless of course you have several similar buttons with only minor differences between them. Maybe copy-paste? And then you have to slightly tweak your buttons... Or add conditional effects or dark mode and the complexity explodes, just on a simple button.

MrJohz 3y ago
The same is true of CSS classes, though - there you have the same choice between reuse and duplication. Do you have .button-primary, .button-secondary, etc, or do you use modifiers instead? The combinatorial complexity is inherent in the design of these sorts of components, you won't get away from it just by using a different tool to write your styles.
- lawn 3y ago
  But CSS handles it much better, which is the point. You separate it into a .button class, and then further specialize it by adding more classes (like ".button .button-primary"). With Tailwind everything is duplicated, but with CSS you can move out the common parts.
  - 5Qn8mNbc2FNCiVV 3y ago
    Nothing holding you back doing exactly the same with Tailwind.
    - lawn 3y ago
      Of course, the solution to Tailwind's problem is to refactor it with CSS classes...
  - pcthrowaway 3y ago
    And to do this with a component framework and tailwind you give your <Button> component some props that customize it. With CSS you also have to worry about the cascade way too much, so while you are doing much of the same work with Tailwind, you get the nice benefit of inlining the styles which will actually apply to your component. Yes, you still have to think about organization and how to make different styles apply to variants of the main class, but it's so much easier to not also have to worry about how cascading rules might apply and constantly check different rules for specificity and overrides
    - tisc 3y ago
      I am curious what you - and with you more proponents of Tailwind in this thread - mean with “component” and “component framework”? I’m also Zen-garden age and with my very limited React experience this does sound like you are meaning a component framework like React, correct? If so; what would be the motivation for using JavaScript to style a button? Call me old - my coworkers do -, but that feels counterintuitive. Please note that I haven’t really formed an opinion on Tailwind yet. This is an honest question.
      - MrJohz 3y ago
        Component in this sense is typically just "a composable unit of UI". That often corresponds well with JS frameworks that want to be able to attach state and behaviour to those units, but you can have components without needing Javascript. For example, partials in classic server-side rendering libraries can be thought of as components, although they tend not be used at such small scales. In CSS patterns like BEM, the B ("Block") is in many ways a component with different sub-elements and states. This is partly why Tailwind provides the @apply directive - it allows you to create "CSS only" components even if you don't have other ways of creating components. That said, other forms of components are often easier to use, and if you already are using them, Tailwind recommends using them for style reuse rather than @apply.
- snowcode 3y ago
  Is this really an argument for Tailwind though? isn't this just an observation that both approaches seem to converge when the systems get very large and complex? At which time the work and effort is the same, except ..in the case of Tailwind you're using a made up syntax, and when writing similar amounts of code using CSS you can do it using the CSS standard. The key difference is that you would have to hope that Tailwind outlives CSS as a standard in terms of tooling and language support and continuing improvements (evolution) over time.
  - MrJohz 3y ago
    Definitely, Tailwind is just one approach to solving this problem, there are plenty of others. That said, one of the big advantages of Tailwind over other approaches, at least in my experience, is that it is far less bound to typical JS workflows, which means if you want to write HTML with your own favourite templating language, you can just drop in the Tailwind CLI and still get a lot of mileage out of the system. Compare that to CSS-in-JS or CSS modules, which are both very specific to the Javascript ecosystem. The other big option is just using a methodology like BEM and being consistent with that, which in fairness also isn't bound to Javascript and has the benefit that - like you say - you're writing CSS as opposed to a DSL that is mostly equivalent to CSS. For me, the problems there come from the lack of tooling for writing really maintainable CSS - stuff like scoping and detecting whether a class is still in use. But it's definitely still an alternative, especially with some of the new features like nested selected that are coming out now.