The irony of tailwind is that it inverts the CSS paradigm. Instead of the cascade and selector tree being in CSS, where it's designed to be, tailwind puts the r

The irony of tailwind is that it inverts the CSS paradigm. Instead of the cascade and selector tree being in CSS, where it's designed to be, tailwind puts the rule and cascade into the HTML. This may be nice, but is definitely suboptimal. Sure, specificity is no longer a problem—but then it never was as much of a problem as we (the designer/developer) made it into (by writing bad selectors). So the work arounds used are: * Tree shaking (only keep the selectors you use, not 10mb of CSS). * Use @extend with your own classes to composite a style (smarter, but you could have used properties or mixins too). * Use compile-time / run-time components that generate HTML with pre-selected classes to increase reusability. (Often followed by tree shaking.) And I guess this paradigm inversion is helpful for those who struggle with CSS. It magics away the understanding of the cascade, selector specificity, z-index, etc. But this is the same weakness that Ruby on Rails gets criticized for: magic doesn't replace an understanding of the language. I tried it too, in earnest, on a real project. I had to implement a simple admin dashboard that was basically just user management and export records. I figured it was suited to such a task. Learning Tailwind has such a high learning curve that I had to put it aside. I just didn't have the time to fit it into the project. I "use" it in a different project or two, one of them is a maintenance project we took over. It feels like another "this is hard, so I'll make a framework to make it easier", and the framework outgrew the difficulty level of the original.