You’re at a restaurant, and there’s an odd item on the menu that you’ve never heard of before, but it piques your interest. It sounds like it might be worth a try, though you’re not sure.
When the waiter approaches your table, you inquire about the dish; he notes that while most people are initially repulsed by its appearance, they should still give it a try because the chef swears that it’s supremely delicious. So, trusting his judgment, you order the dish and wait.
When your meal arrives, it looks just as unpleasant as it did in the menu. But you’re not one to judge—you’re willing to try new things. You carve into a slice of it and take a reluctant bite. And… well, it’s really not that great.
In a nutshell, this was my experience with Tailwind CSS. It’s not the worst thing to happen to CSS, but it’s certainly not the panacea that its supporters claim it is—and, in fact, it has a lot of problems…
This thread was posted by one of our members via one of our news source trackers.
Interesting article, some well made points but it only confirms to me that Tailwind probably is the right approach for me.
Every single approach has a trade off, and that can be presented as a criticism. But that doesn’t mean it might still not be the best approach available. Are the alternatives, whose trade offs aren’t touched on in this article, really better for a particular use case?
Maybe it’s just me, but my HTML is a bit ugly and not very readable anyway. It doesn’t feel like much of a sacrifice to have more, and initially obscure looking, html classes in it.
An example of a criticism from the article that is actually a plus for me:
you’re lying to yourself if you think this is any better than writing CSS directly, or any more maintainable than directly applying inline styles. Because instead of repeating styles in your CSS, you’re now repeating them in your HTML, through class names. In fact, you’re likely repeating yourself three, four, possibly many more times now because you can’t chain selectors.
In my workflow, NOT having to open up a CSS file at all, being able to specify the presentation directly inline inside the view template, is a huge win and avoids disrupting my train of thought. It is massively better than writing CSS directly, for me.
And I can easily use helper methods to DRY up commonly repeated sets of classes (with Ruby on Rails view helpers in my case).
Opinionated is great, but this article reads quite biased to be honest. Just a warning to anyone who reads the snippet without reading the full article and considering for themselves whether alternatives really would be better.
I had almost the same thoughts reading it. I was like: “wait… putting style class names inside HTML is a bad thing?” WTF? I always did it like this – I am not a frontender and I only occasionally need to write HTML+CSS (mostly for hobby projects) and to me that’s actually a good thing. As you said, less interruptions.
I’d be open to something like LESS / SASS / SCSS as well though. But IMO for most small projects any of those would be a total overkill.
I’m personally liking Tailwind. My own pain points with it (minor pain, more like aches or itches…) are around stuff like combining Tailwind’s versions of CSS Grid and Flexbox which I already don’t use frequently enough to remember without constantly checking the docs, but which require enough understanding that now I’m checking two sets of docs instead of one.
My personal sense is that after an initial exposure to it, CSS is pretty good for learning as you go along. I’ve also seen some people say that Tailwind helped them learn CSS itself. So if you’re on the fence between building something and learning as you go vs. building a deep foundation before building something, my advice has to be to just build it. Curious about what others think.
Wow! Had not seen that before. That completely fixes one of the very few annoying things about Tailwind, arbitrary styling that you needed to do custom config or CSS for before. And the build optimization looks amazing.
