| I disagree. I've worked on some pretty beefy projects with both "traditional" CSS and Tailwind. Granted, Tailwind isn't that old in the grand scheme of things so trying to fit it in to legacy projects (5+ years old) can lead to different outcomes. With the old CSS paradigm, I find most of the time you get into a rut where old styles can't be deleted for fear of breaking some obscure part of the experience that development has stagnated on in recent times. Your CSS file continues to grow as new features are added and the old stuff is never reexamined or removed. Who's to say that `P { margin: 0 auto; }` isn't implicitly being used on code being written today? With Tailwind, all of that ambiguity goes out the door (especially with the JIT becoming the default in v3 at the end of this year). If I remove some classes in my markup, I can be confident the CSS file that is generated is optimized to only include what I need and I'm not saving any old cruft. That alone is a huge boon to confidence and productivity. If I don't have to audit old CSS, that's a win. I don't need to think about old CSS during code reviews, etc etc. The other part I find most useful is the elimination of generating novel class names, but I will concede that isn't a problem for everyone. Personally, I find that sort of stuff mentally taxing in a way that I don't enjoy. Finally, I feel like something nobody tends to talk about is that the real power scenario for Tailwind is when it's paired with a framework like React/Vue. The duplication problem is resolved by components that are meaningful to your app, not by arbitrary CSS classes. If I'm repeating the same class over and over again, that's a clue that there is likely a UI component to be extracted. These components also aren't limited to frontend frameworks; nearly every templating language supports partials in some flavor. I'd be interested to hear your full write up. I believe you've experienced pain, but I wonder if in these conversations were are talking past each other or there is some other external variable that the other party is not aware of. For example, at my day job, I do a lot of custom enterprise-y WordPress development. Tailwind is a pretty awful experience to work around in the current WP paradigm. I can relate with teams who may have tried to work in a similar scenario. Tailwind isn't going to solve every problem, but I do think it can provide a lot of structure to teams out of the box with very little configuration, and that is it's primary value add imo. |