As I commented on Mastodon:<p>Today's "Tailwind-in-HTML" is tomorrow's tech debt on a scale we haven't seen since the AngularJS days from a decade ago.<p>It won't be pretty.<p>(But perhaps a future job opportunity for folks who can rebuild design systems using real CSS and web standards.)
I've been working in CSS for over 20 years. I know it very well. Tailwind is also my absolute most favorite technology to come along in a long time. I would even argue to use it effectively you also need to understand CSS well. The smart steering analogy doesn't jive with me at all.
Tailwind is the modern equivalent of Bootstrap.<p>Most teams do not have a dedicated designer. Most developers are quite bad at CSS. These teams, which are most teams, want to ship something that is not butt-ugly and do it fast.<p>That's what Bootstrap did and what Tailwind does. All the endless discussions about the technical merit of inlining utility classes versus hand-crafting CSS are pointless and cannot be resolved because they miss the point entirely.<p>The point is: ship something good-looking very fast by people that suck at UI or don't have proper time for it.
For me, Tailwind takes away a third of the two hardest things in computer science: naming things.<p>Extremely useful when building out a design system for the first time.
The first iterations of tailwind were really interesting. I took a lot of design system concepts from it.<p>There are two problems with tailwind; 1) <a href="https://twitter.com/dillonchanis/status/1706473840367247482/photo/1" rel="nofollow noreferrer">https://twitter.com/dillonchanis/status/1706473840367247482/...</a> and B) the tailwind fan boys.<p>Every project of any decent size needs utility classes. No reason not to use tailwind for those. But every time I head that naming things is hard, I can't take that person seriously. You're not naming a baby. and if you change your mind on .pricing__card__header, just use your editors refactoring tools to rename it.
I don't get tailwind at all. I never pressed the play button in terms of the article, but it's like promoting the use of MS Word without formatting styles... You end up with masses of shitty documents formatted with a wild mix of overlapping formatting options and extra spaces.<p>And yes, I am looking at you, Mom... ;)
I'm glad the writer has actually tried Tailwind and I respect it's not really their thing, but I've got to hard disagree with the Builder vs Crafter/specialist look on it. Tailwind will only just barely save you from not knowing CSS, it's still fundamental to understand it. Also I would consider myself very well versed in CSS, but while my handcrafted css works, it cannot compare in maintainability to its tailwind equivalent. CSS inevitably becomes a spaghetti soup of states after a while. I switched an entire component library to tailwind + tailwind-merge and everything was much cleaner and easier to understand. So much so I could not believe it.
I think the argument about Tailwind is overblown because half the people using it should just be using a component library.<p>Component libraries suck when you need to massage a design system into them. But at least half the arguments over Tailwind vs CSS are devs mostly doing their own thing and touting how easy it is to change X Y and Z. Similarly those same devs <i>hate</i> component libraries because you can't just change X without changing X <i>everywhere</i>.<p>_<p>A little secret they don't realize is, <i>X changed everywhere so that your site wouldn't look like a pile of slop.</i><p>That's why even the darling of the "anti-component-library pro-ctrl+c-ctrl+v establishment" shadcn/ui had to go back and add theming and a component.json.<p>If not using a component library is easier for you, that's a red flag: the alternative should be your team rolled out their own design system, and that's just a different kind of difficult with a different set of trade offs.<p>If you're using a design system, I don't think CSS vs Tailwind is as much of a mortal conflict because the design system provides a map. Usually that map gets translated into something like variables, or even Tailwind Variants, and suddenly the biggest issue with Tailwind (scattering consistent properties across the codebase) is not as terrible as it seemed.
So the takeaway for me here is to avoid dogma, and if your “senior” coworkers are forcing it on you, leave asap. Oh and if you want to be productive, use Tailwind first and hand craft the small percent of CSS where that’s required later, if such a thing actually occurs. Everything else is just religion (in the emacs vs vim sense).
I work with designers who don’t know how to write CSS and who sometimes use Bootstrap for mock-ups (on a system not built on Bootstrap). They spend their whole day in Figma. The designers try to come up with design systems, but never finish them.<p>Tailwind works pretty well for us.
This speaks my heart. Lately I was asked by my team to ditch my own little CSS framework in favor of Tailwind CSS. Beside having an ego problem with it, I'd like to disable 'Smart Steeting' to take shortcuts now.<p>Shameless blog link:
<a href="https://medium.com/teutonic-css/retiring-my-own-little-css-framework-e0a130ca2a33" rel="nofollow noreferrer">https://medium.com/teutonic-css/retiring-my-own-little-css-f...</a>
tl;dr: noobs often like tailwind; veterans often dislike it. Both are right and both are wrong. Context is everything. Tailwind serves a function, but it will never fully replace native CSS APIs. "Can't we all just get along."