That doesn't seem like a big enough win when CSS variables exist and offer far more readable options (as you're the one naming them). On that front, I reckon majority of Tailwind developers use far fewer variables than they believe, so it's not some gigantic monumental task where you have to set up a million different CSS variables.
This is the problem with Tailwind, it doesn't offer enough nor does it move faster than CSS to justify its existence. The only real use case for it seems to be solo developers that do not have the time or resources to set up their own baseline set of variables, or those that use it with a component library that's based on TW.
I think you need a reality check on who actually uses Tailwind. Very large cops and sites use it because it improves the dev exp and increases performance through smaller file sizes. Further I’m not sure what you mean about not moving fast enough, they just added container queries.
I'm working at a small company with about ten employees - realistically max three or four people will work on the styling although a few more will have eyes on it.
We already get massive benefits from it that I wouldn't get as a solo dev. If someone else writes a bunch of new components that make up a new menu and I need to grok them quickly and then start working on them quickly, Tailwind brings the time I need to spend understanding the styling down to nearly zero. It's a massive timesaver for teams of any size.
Yes, you can get some of the benefits with other systems like CSS variables. But not nearly to the same degree, and you'll also need to organize a bunch of CSS/SCSS files besides you main code.
With Tailwind we have something like five small CSS files across a large monorepo that contains several apps.
Yes, and you'll find many of those very large corps are questioning why they're using it now. Which is a great thing, many businesses should be in constant reevaluation of why they rely on certain tooling.
Personally doubt the better performance, I have yet to see a case where that is true unless they were comparing it unevenly to some behemoth like Styled-Components. When you compare it to SASS the performance difference ceases to exist. Same with "improves the dev exp", I don't see how this is the case at all especially when you have to install an additional extension to get full proper support in your IDE of choice. You are still working with variables, if you are on a tiny team/solo, it makes sense to use Tailwind defaults but on a large team where your design team should be creating their own? What use does Tailwind have then when the utility classes are just going to be overwritten? You're still creating the components yourself.
I suggest you double check those performance claims. The CSS might be smallish, but you're usually moving the weight to non-cached HTML which is re-downloaded on every page view. I helped analyze the impact on a very large website (billion+ pageviews) and it did not look very good.
What you are saying is: "tailwind class names are cumulative and so verbosein the HTML tag that it negates the benefits of smaller CSS and eat the bytes saved?". Am I reading that right ?
And this does make a difference when your entire layout is done with Tailwind. Consider that the HTML, unlike the CSS, might typically not be cached, and that the server is now also charged with emitting higher loads of data. Consider also that all these utility classes are all loaded in the CSS on the front page even if some or most of them is used on everything except the front page. The performance win is not as unquestionable as Tailwind would like to suggest.
This is the problem with Tailwind, it doesn't offer enough nor does it move faster than CSS to justify its existence. The only real use case for it seems to be solo developers that do not have the time or resources to set up their own baseline set of variables, or those that use it with a component library that's based on TW.