Josh may have written the perfect article on Tailwind. As someone who has also spent quite a lot of time (both professionally and personally) working with Tailwind, I couldn't agree more, particularly with the final section; every word seems to resonate. It's not that Tailwind is bad, it just breaks everything that I value and locks me off from the tools that make me most efficient.
Which is probably the one aspect of this article I would disagree with. I don't think I agree that I'm less worried with speed or efficiency on the front end. On the contrary, I find my greatest irritation with Tailwind is how slow it makes me. I'm faster using custom properties, leaning into the cascade, getting the most out of CSS power tools like Grid. Tailwind clips those wings and my efficiency with it. But for a junior dev, it is likely quicker (though I'd also argue, puts them at a disadvantage as they grow, and cuts them off from learning fundamentals that will be needed at some stage, Tailwind or not.)
On the "great divide"Â in front end right now:
Many who use Tailwind never want to go back; many who don’t never want to.
How could we possibly disagree so sharply?
On the analogy between Mario Kart's Smart Steering function and Tailwind:
But as you get better and better at the game, Smart Steering begins to help less and less… until eventually, it starts getting in the way instead.
The more skilled you are, the more this feature designed to augment your abilities instead begins to inhibit them.
To those sufficiently skilled with CSS, Tailwind feels like being forced to code with Smart Steering on.
On the tradeoffs involved in any decision:
But complexity always exists, even if it’s remanded to a place you don’t regularly experience it.
Problems in tech don’t vanish; they simply get reconfigured into new shapes, with new pointy edges in new places.
On the hidden complexities of Tailwind
Because Tailwind is often marketed (and spoken of by many of its proponents) as a framework that’s achieved this impossible task of obliterating CSS’s complexity from existence.
If you would make this argument, I would firmly dissent. But I would also agree you’re probably right in your case.
You likely don’t work in the areas where the tradeoffs are, so they might seem like they don’t exist to you.
On the kinds of people that advocate for Tailwind, and why the increased efficiency/simplicity is preferable in this area to them:
This also implies one or both of the following: either a) that they found this work overly challenging before; and/or b) that this is not the part of their job they wish to be challenged in.
On those that use Tailwind as a tool to augment CSS, rather than override it:
Many people who like Tailwind are also very good at CSS, but those Builders tend to be bringing a more balanced approach, where they use Tailwind for the broad strokes of utility classes, and heavily customize the config file and/or write their own CSS to fill in the gaps.
On those of us who dislike Tailwind:
But Crafters generally are less focused on getting through the frontend as a part of that work, and instead see the frontend as the product itself.
At best, it represents a hefty learning curve, just to get back to where they already are.
Where you might see a helpful copilot who keeps you on the track, I see a meddler who gets in the way at the worst possible moments.
On one of the downsides to building quickly:
In my view, the more you optimize for building quickly, the more you optimize for homogeneity.
On how native scoping, cascade layers, new frameworks, and other tools are making the problems Tailwind solves increasingly obsolete:
Point is: I think Tailwind served the world of pre-2023 frontend development quite well. I don’t expect fans or organizations to move, but I do think we’re actively outgrowing the need for it right now. Most of the answers Tailwind provided weren’t otherwise readily available at the time, but they’re now becoming more and more just parts of the platform, and of the other tools we’re already using anyway.