[pverheggen]

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]

> 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]

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

[timr]

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

[Timon3]

It undoubtedly is! I'd much rather learn 10,000 different names that follow a clear naming scheme and stay consistent between different projects and teams, than 1,000 different names that aren't guaranteed to have clear names or any consistency (even inside a single team).

But I'd also like to push back on the "10,000 different names" - the overwhelming majority of those names are merely variations of the value they assign, so using any class teaches you dozens to hundreds of those 10,000 names. So realistically, the comparison is closer to "1,000 project-specific and potentially inconsistent names" vs. "1,000 consistent names valid in any project using TW".

[array_key_first]

Those 10,000 names are already written, though.

Tailwind doesn't solve technical problems really, it solves social ones. In a perfect world we all write vanilla CSS. But, in my experience, it becomes extremely messy and hard to reason about in huge codebases with lots of developers. Which sucks but isn't surprising to me.

[xigoi]

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

[zelphirkalt]

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.

[9dev]

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]

If this was the case, it wouldn’t take several seconds to open devtools on sites that use Tailwind.

[9dev]

That is only the case for sites that include the entire, unpruned Tailwind Stylesheet with all utility classes. That’s a choice…

[satvikpendem]

CSS modules solve all of these problems.

[9dev]

They don't, really. The only thing they solve is side effects, but you'll still want shared conventions across your modules.

[satvikpendem]

If you're using components, it's the same as Tailwind, just put your CSS module files next to the component, or use compile time CSS in TS frameworks like PandaCSS to have them in the code itself. For shared conventions that is the purview of the design system and you'd have CSS tokens for various colors etc. Anything you can do in Tailwind you can of course do in CSS modules because it's CSS at the end of the day.

[9dev]

That isn't just CSS modules, then, but additional tooling on top.

[zelphirkalt]

I for one do not understand what is so difficult about making a team internal decision about how some "component" (here in quotes, as I am actually thinking of an HTML subtree with specific purpose somewhere on an HTML page) is going to be named, and then give it that name as CSS class. Are people never talking with each other? Are people unable to grep a code base, before making up a new name? And how many similar but not same purpose things do you have on your pages, that this becomes a serious problem? Or is it just a discipline problem? People can name hundreds of useless OOP abstraction classes, but cannot be bothered to think of a good name for a "component" on a web page?

I mean, come on, there is usually tons of context and team internal language for the new thing to build and to talk about it, distinguishing it from the old thing that was already built.

And if that's too hard, then allow the design department to name the things they design and notify them about any clashes. They must have a design language anyway.

[9dev]

Again, this isn't really about difficulty—you can solve problems of arbitrary complexity by establishing a process, guidelines, rules, and documentation. But unless your goal is maximising the number of meetings you need to communicate arbitrary naming conventions, having a framework that takes these decisions from you is an efficiency boost. There will always be new invariants, combinations, or elements to style.

Say you have a .button class for clickable button elements. One day a junior engineer realises they need two of them next to each other, while one is more important. Predictably, as they don't want to bother one of the seniors with this, they are going to introduce a .secondary variant. A few days later, someone else gets tasked with introducing a variant prop for <div class="card">, so the upsell banner can be styled differently easily. "Oh!", they think, "Neat! there's a secondary class that sets all the same props I need!"—and just like that, coupling was introduced.

Sure, this is a contrived example. The junior could have scoped the class to buttons; or added an explanatory comment; or written a note to the team; or asked a senior; someone could have seen it in code review; or a heap of other mitigations. But all of these happen to fail sometimes, and compound over time. This isn't even really about CSS, but entropy at the end.

So to me, this is the benefit Tailwind brings to the table: By providing a styling language that doesn't require making up rules as you go, that scales to arbitrary project sizes, and most importantly doesn't need additional communication, you get optimized, side-effect free CSS that you will immediately be productive in, even as a new joiner or when you return after a long time.

[troupo]

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

[pverheggen]

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]

> 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]

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]

In any real application you will have far fewer semantic class names than combinations of style properties. Working with concepts is vastly easier than trying to remember the specific property differences between concept A and concept B.

Obviously, a real application will have more than one css property. Also, your widgets will share styles, usually in a fairly obvious hierarchical way. And your designers will want them all to be consistent.

In this world, it’s far easier to remember that a widget is “.widget”, and that “.rounded-widget” is for the round version of that”, than it is to remember that the former concept is “.b1p .m5 .ib .xyz .pdq .foo” while the latter is “.b1p .m5 .p2 .br10 .xyz .bar”

[xigoi]

> Well, instead of repeating inline class names everywhere, you end up with CSS properties repeated everywhere. Not really seeing the difference.

It’s like the difference between

  app_name = "Foobar"
  print(f"Welcome to {app_name}")
  print(f"Learn how to use {app_name}")

and

  print(f"Welcome to Foobar")
  print(f"Learn how to use Foobar")

Any good programmer knows why the former is better.