Sorry but why would you write a latency sensitive, text processing heavy tool like this in Javascript? Highly likely this won't scale well in future. One would think the resounding success of esbuild would inspire next generation of front-end tools to be better but this is just disappointing.
I see the arguments back and forth. But this is just classes replacing styles, with a cascade that can't be controlled from HTML. I see no advantages over CSS, and a huge cognitive load for using Tailwind.
Adam Wathan is brilliant. But I don't see a practical advantage.
I thought exactly the same. As a long term front end developer from the "CSS Zen Garden" school of web design circa ~2000, I've always felt these new kids on the block should just stop inventing convoluted workarounds for just _learning fucking CSS_. I've always felt those kids all came through boot-camp coding schools that taught CSS as an afterthought, and mistakenly see its best features as problems that need disabling. I thought Tailwind looked like the very worst such offender. Tried it (in earnest on a real project) after reading so many smart people saying "honestly, it sounds insane but you just have to try it (in earnest, on a real project)". I now love it. It turns out it is spiritually very close to writing normal CSS – in fact I'd say you really have to know CSS to use Tailwind; you are just writing CSS with it and you have to be hyper-aware of its output. Oh and you do still sometimes write the odd bit of plain CSS for ultra-specific situations – Tailwind is absolutely fine and compatible with that, which you can't say for other modern styling tools. I'd say it's more a complement than an alternative to writing real CSS. It leans into and exploits the special features of CSS (cascading, inheritance etc) instead of trying to 'disable' such things. It's truly a great tool, a once-in-a-decade, outside-the-box brainfuck that I never saw coming. It's not the end-all solution for all kinds of modern front end styling, but I see it as an extremely valuable addition to my toolkit. The name "Tailwind" really is apt, it unlocks a strangely powerful creative impulse that lets you just fart out well-constructed, efficient UI like it's nothing. Takes a little while to get into it (you have to take the time to set up your editor for autocompletion and documentation etc) but after that, it's just so nice to use. One other thing to note is it's not necessarily a 'forever' decision in a given project or component: I some I use it when sketching out new components, and then convert it to regular CSS-and-classnames or whatever once the component is stable and done-ish, depending on the use case or project requirements. It's just a tool, but a very good one.
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.
That is how it seems to look like to me too - I like the idea of controlling the CSS from one place, but it does feel like trying to jerry-rig the CSS to work in a way that it was not intended to be used.
But maybe it is a non-issue when it is being used in component context, where there might not be any relationship style-wise between them
