There are enough people who advocate for Tailwind that I can't dismiss them in good conscience, but if you put a gun to my head and forced me to give my honest opinion, I can't think of a single problem that Tailwind solves that isn't better solved by web components and scoped CSS, BEM, or a decent CSS-in-JS library.
When I see articles praising Tailwind, they're almost always comparing it to the worst possible way to write CSS -- a mixture of arbitrary classnames that get reused across components and semantic styles that refer directly to HTML and use child selectors to target specific elements.
Well yeah, if you compare Tailwind to that, it probably looks great. If you compare JQuery to building HTML templates in PHP using string concatenation, JQuery probably looks great too.
Again, I can't dismiss it, the people advocating for it must know about these other solutions. I can't dismiss them. But I don't understand it. And the articles that are written about why it's good are entirely unpersuasive. They're talking about problems that I consider to be already solved.
People advertise Tailwind by saying "we want the styles to be based on the component." Yeah, I want that too, but it sure looks Tailwind is a really inconvenient, cumbersome way to do that. You can scope CSS to components if you want to, that's not something that requires Tailwind.
The moment you start working outside of the React bubble you begin to discover just how many of these problems are solved by things like Svelte/Vue's single-file components and a few decent editor extensions.
I don't have to go hunt for a separate CSS file to see what is happening with my semantically named classes. I don't even have to scroll to find it in the same file, I can just option-click the class and see a mini-window showing the relevant styles, edit them inline, or jump to where they are in code. I can find out which classes are unused or where they are used. I get the best of both worlds.
Additionally the moment you get into anything beyond basic layouts the readability of Tailwind drops from "a little frustrating" to "completely opaque". Start adding new CSS features like variables, wide-gamut colors, sub-grid, etc and your neat Tailwind classes start looking like abstract [ ] and letter soup.
Tailwind has some really cool benefits like helping you stick to consistent tokens from your design system and being able to copy paste most HTML from one project to another and have it work, but those benefits simply do not outweigh the downsides I find when I am working in a real project I have to come back to edit and iterate on with multiple people who don't all know CSS well.
> and being able to copy paste most HTML from one project to another and have it work
coughweb componentscough
I don't want to be derisive about it, but... yeah, agreed. I just feel like these are solved problems and Tailwind proponents are acting like it's novel that Tailwind helps with them. My immediate thought on hearing about even the benefits you bring up is that this doesn't seem like a realistic scenario?
One of the stated benefits of Tailwind is that it addresses this concern that the HTML and code/logic and CSS aren't meant to be separated from each other and they interact so much. Well, given how tightly coupled HTML and logic often is, how often does it actually happen where you can copy HTML from one project to another and not have to reformat it from one framework into another -- if you're writing React you're already coupling that HTML to your code. If you're writing Svelte, you're using Svelte templates that won't be present in Vue.
And if you're using CSS-in-JS, or heck, any scoped CSS solution at all then copying over that HTML means copying over the HTML and then... also hitting copy-paste on the block of CSS. That's not exactly a major time save. And even there -- how often am I going to import a block of HTML into a new project and not want to change the CSS to match a new style guide?
There is a solution that allows you to basically import everything without worrying about whether it fits the rest of your application logic and styling though: web components. I don't personally get a ton of use out of them in my own development, but they seem basically decent and they seem like a much better solution if someone is worried about having a shared component library across multiple apps?
---
I can't dismiss that there are developers that I respect who say Tailwind is great. I am not going to say that they're bad at CSS or they're inexperienced or something, that's clearly not the case. But I just wish they could explain what they're getting out of Tailwind in a way that I can understand. "You have to try it to understand it" -- I have tried it, I still don't understand it.
It doesn't help that so many of these arguments start with "imagine not needing to worry about specificity." I haven't worried about CSS specificity in years.
When I see articles praising Tailwind, they're almost always comparing it to the worst possible way to write CSS -- a mixture of arbitrary classnames that get reused across components and semantic styles that refer directly to HTML and use child selectors to target specific elements.
Well yeah, if you compare Tailwind to that, it probably looks great. If you compare JQuery to building HTML templates in PHP using string concatenation, JQuery probably looks great too.
Again, I can't dismiss it, the people advocating for it must know about these other solutions. I can't dismiss them. But I don't understand it. And the articles that are written about why it's good are entirely unpersuasive. They're talking about problems that I consider to be already solved.
People advertise Tailwind by saying "we want the styles to be based on the component." Yeah, I want that too, but it sure looks Tailwind is a really inconvenient, cumbersome way to do that. You can scope CSS to components if you want to, that's not something that requires Tailwind.