4 ms·

Tailwind, JS-in-CSS, and the like have become popular because they work well with the modern corporate UX workflow. A Figma component has a certain set of style

Tailwind, JS-in-CSS, and the like have become popular because they work well with the modern corporate UX workflow. A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste.

timr 5mo ago
> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. This is what CSS classes were made for. Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. > And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition! > There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste. ...and now you have three problems.
- 9dev 5mo ago
  > This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt? > Sure, sure. except for the inline styles everywhere. There are no inline styles when using Tailwind. There are references to variables from the design system. > And the fact that everything is literally being repeated all over the place. If you find yourself repeating the same sequence of classes, it's time to create a component in your frontend framework if you use one, or a Tailwind utility class. And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely.
  - xigoi 5mo ago
    > And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely. The client still has to decompress it and waste processing power parsing all the repeated text.
    - 9dev 5mo ago
      Premature optimisation doesn’t even fully express how absolutely ridiculously futile it is to try and make your website faster by having fewer CSS selectors. It’s like my grandparents worrying about immediately switching off their LED ceiling lamps when they leave a room - meant well, but utterly meaningless.
      - xigoi 5mo ago
        If this was the case, it wouldn’t take several seconds to open devtools on sites that use Tailwind.
        9dev 5mo ago
        That is only the case for sites that include the entire, unpruned Tailwind Stylesheet with all utility classes. That’s a choice…
    - zelphirkalt 5mo ago
      Additionally, I do not think, that copy pasting a CSS class name everywhere is a realistic sane use-case. Usually, one would render some template and that template lives only in one place in some file, not all over the codebase. If we go smaller than a template, to use jinja language, we have macros as reusable parts, also not having them all over the codebase. It rings like a gigantic strawman to me.
  - timr 5mo ago
    > That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt? Of course. It's obviously better to have 10,000 different names that are all loosely, but not exactly the same as the CSS property they're trying to represent.
- pverheggen 5mo ago
  There are a bunch of differences between Figma styles and CSS styles that prevent you from creating a 1:1 mapping: typography inheritance, spacing rules, and variant specificity to name a few. Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there. > Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition! Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
  - timr 5mo ago
    > Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference. Erm...what now? That's so off-the-wall that I can't even wrap my head around your meaning. Are you trying to argue that because, say, a conventional CSS file has "border:1px" in multiple places, this is somehow equivalent to the Tailwind approach of making a "b1p" class that captures the same thing [1], and plastering it across your templates? Because a non-abusive application of CSS would actually just put that border property in a semantic class like ".widget" or something, and sure, you'd have multiple "border:1px" declarations across all of your CSS files, but that's irrelevant, because you're not trying to reconstitute every style inline from pseudo-properties. [1] I am making this example up for illustrative purposes.
    - pverheggen 5mo ago
      Yes, that's exactly what I'm saying. You don't end up needing a semantic class like .widget since you likely already have a Widget component in your codebase. Essentially: .widget { border: 1px; } ... const Widget = () => ( <div class="widget"></div> ); vs const Widget = () => ( <div class="b1p"></div> ); You keep saying this is an abuse of CSS and that's not how it was meant to be used, but why is that so important?
      - timr 5mo ago
- troupo 5mo ago
  > but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. Yes. And as 30 years of CSS show, it's not enough. > Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. It's not repeated all over the place, because in your codebase you have a single place where component A is defined. A single place where component B is defined etc. I don't see you complaining about having to repeat the same CSS properties (padding, margin, display etc. + responsive styles + hover/disabled etc.) for half of the components when writing vanilla classes.

timr 5mo ago

> A Figma component has a certain set of styles, you apply those same styles to the corresponding React component. This is what CSS classes were made for. Of all of the arguments in favor of Tailwind, this is the one that drives me battiest. Say what you will about CSS, but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. > And none of this really violates DRY, your unit of reuse has shifted from a CSS class to a framework component. Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition! > There's nothing precluding you from using an approach like DaisyUI if stock Tailwind has too much repetition for your taste. ...and now you have three problems.

9dev 5mo ago
> This is what CSS classes were made for. That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt? > Sure, sure. except for the inline styles everywhere. There are no inline styles when using Tailwind. There are references to variables from the design system. > And the fact that everything is literally being repeated all over the place. If you find yourself repeating the same sequence of classes, it's time to create a component in your frontend framework if you use one, or a Tailwind utility class. And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely.
- xigoi 5mo ago
  > And even if you just copy-paste the same class strings all over the codebase, transport compression will eliminate that pretty much entirely. The client still has to decompress it and waste processing power parsing all the repeated text.
  - 9dev 5mo ago
    Premature optimisation doesn’t even fully express how absolutely ridiculously futile it is to try and make your website faster by having fewer CSS selectors. It’s like my grandparents worrying about immediately switching off their LED ceiling lamps when they leave a room - meant well, but utterly meaningless.
    - xigoi 5mo ago
      If this was the case, it wouldn’t take several seconds to open devtools on sites that use Tailwind.
      - 9dev 5mo ago
        That is only the case for sites that include the entire, unpruned Tailwind Stylesheet with all utility classes. That’s a choice…
  - zelphirkalt 5mo ago
    Additionally, I do not think, that copy pasting a CSS class name everywhere is a realistic sane use-case. Usually, one would render some template and that template lives only in one place in some file, not all over the codebase. If we go smaller than a template, to use jinja language, we have macros as reusable parts, also not having them all over the codebase. It rings like a gigantic strawman to me.
- timr 5mo ago
  > That brings with it the problem of naming a thousand things in a consistent way that everyone on your team needs to understand and remember, otherwise you end up with tons of duplicated classes, parallel systems, and bike shedding. Have we, as an industry, not felt this pain often enough yet? Do we really need to keep banging our head against the wall to figure out it does hurt? Of course. It's obviously better to have 10,000 different names that are all loosely, but not exactly the same as the CSS property they're trying to represent.
pverheggen 5mo ago
There are a bunch of differences between Figma styles and CSS styles that prevent you from creating a 1:1 mapping: typography inheritance, spacing rules, and variant specificity to name a few. Like yes, CSS by itself is extremely powerful, but I see no reason why you should feel beholden to use all of its features simply because they're there. > Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. But other than that, no repetition! Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.
- timr 5mo ago
  > Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference. Erm...what now? That's so off-the-wall that I can't even wrap my head around your meaning. Are you trying to argue that because, say, a conventional CSS file has "border:1px" in multiple places, this is somehow equivalent to the Tailwind approach of making a "b1p" class that captures the same thing [1], and plastering it across your templates? Because a non-abusive application of CSS would actually just put that border property in a semantic class like ".widget" or something, and sure, you'd have multiple "border:1px" declarations across all of your CSS files, but that's irrelevant, because you're not trying to reconstitute every style inline from pseudo-properties. [1] I am making this example up for illustrative purposes.
  - pverheggen 5mo ago
    Yes, that's exactly what I'm saying. You don't end up needing a semantic class like .widget since you likely already have a Widget component in your codebase. Essentially: .widget { border: 1px; } ... const Widget = () => ( <div class="widget"></div> ); vs const Widget = () => ( <div class="b1p"></div> ); You keep saying this is an abuse of CSS and that's not how it was meant to be used, but why is that so important?
    - timr 5mo ago
troupo 5mo ago
> but "give a name to a re-usable set of styles for a component" is pretty much as fundamental as you can get. Yes. And as 30 years of CSS show, it's not enough. > Sure, sure. except for the inline styles everywhere. And the fact that everything is literally being repeated all over the place. It's not repeated all over the place, because in your codebase you have a single place where component A is defined. A single place where component B is defined etc. I don't see you complaining about having to repeat the same CSS properties (padding, margin, display etc. + responsive styles + hover/disabled etc.) for half of the components when writing vanilla classes.