[throwaway150]

Absolutely! There are so many problems with Tailwind.

The HTML is littered with styling information. Reading HTML should be about content and meaning, not knowing that "pl-16 pr-8 bg-olive-500 text-gray-700" means "this is probably a card header". But... you might argue that people do not read HTML anymore. Yes, people don't read HTML anymore. Who would when the devs using this framework turn the HTML into a horrible mess! If you litter your HTML with so many framework classes, there is more noise than content in HTML. Is it a surprise that reading HTML has fallen out of fashion? And since nobody reads HTML anymore, devs are totally unhinged with cluttering it with more and more classes and styles. It's a self perpetuating cycle.

Webdevs do style duplication rampantly. Instead of something like ".button", you'd find stuff like "text-white rounded bg-gray-aaa" littered throughout hundreds of places. I'm not sure if this is a Tailwind problem or dev problem but the problem definitely is there. A large project would soon reach a situation where if you want to make a style change across all similar UI elements it's a whack-a-mole game to find out which inline styles in which elements you need to look at.

[brailsafe]

I have a fairly strong grasp on CSS, at one point having what I felt was as close to as knowledgeable as I'd care to be about it, but one thing always stuck out as a neverending battle; style organization. I think Tailwind does have all those problems to some extent, but CSS alone didn't find cultural consensus around how best to implement it, always leaning on whichever flavour of the month conceptual framework that was often just one more system to try to manage. There's some virtue in writing the stuff you do cleanly, but sometimes it's just not as valuable to someone who's primarily doing what could be described as complex software development. Sometimes the marginal benefit to a clean implementation and a slightly messy redundant one of the same interactive caliber just isn't that important relatively, especially when the negative qualities are somewhat mitigated by component re-use and scoping.

[chuckadams]

I think it's the complex specificity rules that prompted things like TW to come about. Sure it's useful and powerful but it's utterly baffling to reason about, especially when everyone's conventions work at a different level of specificity. Trying to tame specificity gave us cumbersome structures like BEM, and TW came about as an act of rebellion against such things.

Conversations about CSS complexity always remind of this quip: "Two CSS selectors walk into a bar. A bar stool on the other side of town falls over."

[ookblah]

yeah, and then one day you want .button, but with a variation. GREAT. but oh no, now there's this other button that has a little bit of a change but not enough to create a separate class. maybe we'll just inline it... but no, i need a mobile selector here or i have some complex hover style. i know, let's create a basic utility class to help me out here. hmm, starting to look suspiciously like tailwind...

now multiply this problem by more people working on an app, with different isolated components that they never even dreamed of during css zen garden's time and this is how something arose. we've tried creating centralized css sheets and it just doesn't work at scale.

so yeah, a necessary evil, but i wouldn't call it an anti-pattern. it grew out of real needs. we had bootstrap and all these css frameworks attempting to make "order" about of something that honestly after decades of working with i don't think can be ever be fully "clean". people just gotta move past it.

[troupo]

> Reading HTML should be about content and meaning, not knowing that "pl-16 pr-8 bg-olive-500 text-gray-700" means "this is probably a card header".

Unlike vanilla CSS where you need to look at browser dev tools and computed styles to figure out why something is styled this way. Because of course it's not styled just by the `.jus-one__more--modifier`.

And Tailwind is mostly there for people developing sites/apps, not reading final HTML. So all that is usually contained in the specific component.

[chuckadams]

It's a culture problem with Tailwind devs: for a long time there was a crusade against `@apply` in favor of inlining every class. I think the reason was solely because TW's tree-shaking wasn't very capable then and did even worse with @apply, but the air was thick with specious "philosophical" justifications flying around for inlining all the things. The most typical was "it should always be done through a component toolkit", which of course just buries the problem in javascript -- not to mention doing it dynamically is incompatible with tree shaking, so you end up having to predeclare everything you use...

Nowadays the anti-@apply contingent seems to have gone quiet, so it is possible to not only use TW and similar toolkits sanely (which has always been the case) but to even see people publicly advocating for sanity.