Josh Collingsworth:
Many who use Tailwind never want to go back; many who don’t never want to.
How could we possibly disagree so sharply?
After using Tailwind for a good while now—both professionally and on a few small personal projects—I’ve come to what might just be the most unpopular opinion of all, in regards to that question:
Both sides are right.
Classic rock, Mario Kart, and why we can’t agree on Tailwind
I think Josh has got it. He put to words what a lot of us are feeling who are genuinely trying to understand the divide, not pick a side, even if we have a preference of our own.
There are different approaches to writing CSS, and they fit people with different dispositions and proclivities. And as much as it pains either “side” to admit it, neither using Tailwind or not using Tailwind is wrong. Unless, of course, you’d be much happier or more efficient using the approach you currently aren’t.
I think the Smart Steering analogy is pretty apt. Tailwind keeps you consistent, but might also be stiffeling (just one of the tradeoffs). I’ve also thought of it as “bumper bowling” for CSS. Keeps you from mistakes, but it ain’t the real thing.
I did “semantic class names” for a decade or more. I hope to never do another site without Tailwind.
I feel a little triggered by the bumper bowling analogy. I have encountered literally zero features that I can’t deliver with Tailwind.
It’s not that you can’t do things (you ultimately have CSS files you can add stuff too, yes? so there is literally nothing you can’t do) — it’s that the tool encourages the use of an intentionally limited set of configured class names, which delivers consistency. Delivering consistency is what bumpers do.
That’s fair, thanks for that.
I guess the bumper bowling thing makes me think “childish”, “novice”, “unskilled”.
Also, I don’t find the initially limited set of class names to be central to my experience when using Tailwind. The first thing I do is comb through Figma and set up all the fonts, colors, etc that I’ll need the in tailwind.config.js file. I then don’t think much, or at all, about the Tailwind native classes, as the ones I do use are extremely intuitive (space-y-10, say).
I dunno. I find myself immediately productive and “in the zone” with Tailwind in a way that’s only possible in traditional CSS during the initial phases of the project. This advantage multiplies as time passes and team members come and go.
I certainly agree with you that it’s weird to get internet-mad about it, as admittedly some people do. I don’t tend to think much about that.
The main thing I think is interesting is the meta issue: Why do we care this much? Why do I care why people care this much?
My theory is that CSS holds a unique position among all development languages: Nowhere else in the stack is there a language that is so easy to learn but so difficult to master. Nowhere else in our work is there a task where progress is so fast at first, and so slow as time passes.
A much more succinct way to say that is the “append-only stylesheet problem”.
I think those frustrations of traditional CSS are a bit visceral! A bit a humbling! And counterintuitive and surprising. I think that’s why it’s such a trigger-prone subject.
@Scott,
People care and must care because trends/progress have consequences even on people who don’t follow/like them.
Our beautiful discipline/industry is a market and is thus subject to market practicalities. That means that the more Tailwind or React are used by “the common consumer” (or developers, here), the more it is asked of any developer to get used to it, more or less crowding out alternatives as the market evolves.
I don’t think CSS will ever go the way of the Blockbuster (ahem), but trends can make it difficult for developers to find CSS work in the wild.
That’s a good point. When tech choices aren’t made by those who ultimately have to use and maintain them, the “everybody is right” thing doesn’t work.
I must say I think you’re right; there’s room for both. I prefer adding Tailwind to my sites but I’m not afraid to step out of the framework when it’s needed, and because I don’t want to add CSS animations to my tailwind.config.js
I worked on a massive Drupal site recently and we just had to use CSS for certain things; Drupal by default spits out so many nested divs it really wouldn’t have been possible to do certain things with Tailwind alone.
I can understand that. Myself, I work with WordPress, and I go to sometimes extreme lengths to make WP spit out Tailwind classes.
It would be daunting or impractical for a beginning WP developer, say, to go to such lengths. It was a chore for me at first but now it’s just part of the bootstrap that I start all my sites with.
I strongly prefer that struggle over the struggles common to traditional css.
Modern CSS features like clamp (which is not supported by Tailwind as of now), layers, specificity selectors, coupled to rational linting of CSS files with Stylelint solve almost if not all problems mentioned as reasons for Tailwind usage. No need to name everything, no shipping of unused CSS, no specificity wrestling, etc.
And many, if not all, of the advantages usually mentioned by proponents (or its website!) are not specific to Tailwind. For example, design tokens? Well, CSS have them too and you can even have the same exact ones..! By taking all of this into account, it seems that Tailwind (and yes, I have used it for years) is giving less and less bang for the proverbial paid bucks in complexity, dependencies, growing syntax, build overhead, etc.
But, hey, I’m always opened to new arguments!
Everything Emma said.
I use, and will continue to use Tailwind. Even though I’m always pushing it with some of the modern stuff CSS has to offer. Forcing me to often write custom utilities or just custom CSS in general… And in doing so, making me miss doing that more often.
I fully appreciate all the problems Tailwind solves, I hate few things more than opening an older CSS file to see naming conflicts, unused CSS (maybe? we can’t know for sure!) and even !important rules. The amount of pain that can happen in a single CSS file when it changes multiple developer hands is impressive.
Anytime I work on a tailwind project, I can pick up and go right away.
I definitely see arguments for frameworks becoming less of a requirement, for us (at least in the near future) we still work with developers that aren’t in-house, so it’s more difficult to enforce a consistent build system than it is to enforce the framework.