I stayed away from Tailwind for the exact reasons you described until i joined a company that used it heavily and now I really see the value of it. I’m weary of new tools and cargo cult but Tailwind won me over.

It really shines for apps that are changing rapidly and are at risk for generating dead CSS, which has been a problem in pretty much every commercial codebase I’ve ever worked on. Tailwind adds a simple, straightforward, one-way-to-do-things approach that creates a much more maintainable experience in HTML templates that results in zero dead CSS code.

It’s absolutely not for people that need fine-tuned CSS APIs like animations, etc. But for building a product rapidly, it’s become a go-to for me.

I get the challenge of dead CSS, I think there are strategies for managing that in complex apps without "ditching" CSS. And my understanding of Tailwinds is that it starts to break down for larger/complex apps also (but I've only used it on smaller things personally so that's just based on things I've read).

I never try to be dogmatic about new things - so I'd try it again. I just haven't seen the benefits yet myself and so default to the cons I expressed earlier.

> there are other strategies

True, but those usually involve adding some sort of linter to ensure that your style sheets are clean, which is an additional build step, which is an opportunity for a build to fail. Tailwind gives me this out of the box and doesn’t require any sort of manual lifting because it does this automatically.

> Tailwind starts to break down for larger/complex apps also

This hasn’t been the case for us, I’m on a team of about 50 devs contributing to a 2 year old monolith and Tailwind hasn’t once gotten in my way.

Thanks for the data point re: larger apps. Like I said, haven't had that experience with Tailwinds specifically so I can only go by the various things I read about those who have. I'm sure it's like any other tool - it can be used or abused.

> at risk for generating dead CSS

For what it's worth, in SvelteKit CSS is per-component and you get warnings for unused CSS selectors.

Styles get stupid when they're not local, it just creates a huge hassle as projects scale. The only answer is a css file per component, or css embedded within the component directly. This css has to have a preprocessor or you won't be able to maintain a functional design system or any stylistic consistency. So you're stuck with sass/less/tailwind regardless.

Style classes are IMO the neatest way to inject styles, having elements get styles based on html structure makes code brittle and hard to reason about. If you need an example of this try playing with bootstrap forms.

I actually agree with most of your comment. Just not that Tailwinds is the best way to actually do the styling. I don't have any issue having some form of compilation/processor step that takes colocated CSS and creates a final output, that isn't my objection to Tailwinds, in case that wasn't clear in my original comment. I prefer to actually use CSS, most often via style classes.

And I did not say to base styles on html structure - you are correct, that is brittle and actually one of the things I often ask about in FE interviews as a way of determining skill level. I said that good html structure makes CSS much easier, if your structure is bad, it can significantly compound the amount of CSS needed in order to achieve the desired outcome. So I believe there is a significant distinction in those two statements.

Yep, the only even kinda maintainable CSS ends up being tailwind but in another file.

   <div class="unique-component-name">
      <input class="unique-component-name-input" />
      <p class="unique-component-name-text">Blah</p>
   </div>

   <div class="unique-component-name unique-component-name-variant1">
      ...

   .unique-component-name {
      ...

The cascading in HTML makes the thing that should be easy, creating variants with slight tweaks the most painful thing.

@layer has made all this much easier using raw CSS. One creates sensible global defaults in a `@default {...}` layer, and then they overwrite in a `@custom {...}` layer.