Let us open Schrödinger's Box to see what's inside. Spoiler: It's a dead cat.

George

Future

Community Picks is a section on daily.dev where our community members share the most interesting and valuable content they've discovered online. From insightful articles to handy tools, every post is a gem curated by our dedicated coomunity. To contribute to Community Picks, you need to have at least 250 reputation points, ensuring that only active and trusted members can share their finds.

Community Picks

The post critiques Tailwind CSS, arguing that its utility-first approach isn't new and has significant downsides such as bloated HTML, unnecessary naming conventions, and larger bundle sizes. It suggests that using Tailwind can hinder learning essential CSS patterns and result in code that's less readable and harder to maintain. The author emphasizes that traditional CSS practices and newer tools like CSS Modules and ShadowDOM are more efficient and sustainable for web development.

Tailwind is an Anti-Pattern

Just because an idea isn’t new, doesn’t mean there’s no value in revisiting it.
The nav example is quite odd to me. Styling on a child element tag type seems much more of an anti-pattern to me than giving the element a couple of classes.
Having gone from css &gt; scss &gt; css-in-js and now tailwind, I find tailwind to be by far the most pleasant to work with. It cooperates with other frameworks and packages really well, and I’ve never had this problem of thinking html is unreadable because it has a few too many classes. Especially when it is very clear what each class does.

I think this story can be best summed up with “I don’t like tailwind and you shouldn’t either”. That doesn’t mean he doesn’t make valid arguments, but i only see trade-offs and no “anti-patterns”.
Just like any tool, Tailwind can be used in the right context. That isn’t always a matter of what the technology is but in which team it’s being used. I have made a few websites with Tailwind that have come out great. The maintainability of those project are minimal when it comes to frontend. You can find the element very easily by copy pasting the string of classes in a search and then you can see immediately what you can change. Me and the team im working in find it easy to see at a glance what is happening, even if there are long strings of classes. We usually use the classes in a certain pattern so we know where in the string we need to look
Yes, everything in Tailwind can also be easily achieved with normal CSS, but im not making an argument that Tailwind is better. It’s mostly just preference of the person or team who is working on it. Saying that @apply is bad because then you can just use normal CSS can be a valid point, but the reverse can also be true. @apply can be good because you can use the same syntax as the rest of the project that is easy and quick to write. Its still easier for me to write ‘absolute’ then ‘position: absolute’. It’s easier for the team that also consist of backenders to not have a styleguide with them when they have to change 1 little element that got changed with their code. Everything in tailwind is either standardized or can be configured that way.
Conclussion, Tailwind is a tool not for everyone, but is not a “anti-pattern” as this article makes you believe. It has a place in development if you and your team want to use it.

I totally agree with the article. If you don’t know W3C states that class name should indicate what the element represents, not how it looks like:
<a href="https://www.w3.org/QA/Tips/goodclassnames" target="_blank" rel="noopener nofollow">https://www.w3.org/QA/Tips/goodclassnames</a>
Other than that, I don’t see difference between Tailwind and writing inline CSS, except that the latter is more flexible and doesn’t require learning and implementing a framework (but is just as ugly).
I don’t comprehend why anyone who has autocomplete in IDE would want to write in components cryptic classes instead of semantic CSS. I guess Tailwind finds favor among lazy people who suck at design and wanna have stuff predefined by someone else.
But I could be wrong so tell me why you really use it.

The truth is CSS classes, ids are nice and semantic… on paper. In prod, especially in projects that passed from one developer to another didn’t aged well.
Tailwind is ugly, it’s primitive but it’s damn right effective. The speed it gets the shit done is unmatchable. Also the verbosity and the apparent missing of elegance are matched by IDEs specific plugin.
In the end there are bills to pay and users to serve content and your users don’t care a bit of your html.

First things first, the better you know CSS the better you make use of Tailwind - and other non-opinionated CSS frameworks around.
Let’s talk about all you pointed out.
1 - Bloated HTML
Performance matters, right? A large DOM tree can slow down page performance, BUT dozens of classes don’t affect DOM tree sizes! DOM nodes do.
A parchment of classes in one line of HTML code doesn’t mean you’re harming performance but only human readability.
You stated that using @apply defeats the meaning of using Tailwind. Well that depends. What’s the meaning of splitting JS code into components? Is to avoid duplicating things and thus improve code management, right? Same apply to CSS with… @apply.
And talking about code management there are plugins that you Lint your code and combine with Prettier to organize all TW’s classes sorting then by an intrinsic meaning, so that mitigates the risk of your team commiting non necessary changes.
2 - Naming things
“‘Something that doesn’t deserve to be named’ also doesn’t deserve utility classes.” that’s the purpose of utility-first approach in the first place, isn’t it? After all it is non-opinionated.
Yes there is a plenty of naming patterns we can make use, but as I mentioned above, this goes beyond the purpose of the utility-first approach. Something that don’t even need best practices here. You must understand that.
3 - Jumping around files
Speaking of best practices, it’s really helpful split content from layout and behavior, but when you create components and microcomponents you’ll see a bunch of classes with the content can - and will do - improve your productivity. It’s a matter of time to notice that.
4 - Changing CSS is scary
Yeah could be. But hey, Rust or C++ are also scary to me. So I’ll leave this blank just because it’s your personal assumption. What is scary to you maybe not for someone else.
5 - big bundles
You state “Most websites ship a lot of unused CSS — Tailwind or not.” and I won’t disagree. But point that out as a con is not fair. And take <a href="http://tailwindui.com" target="_blank" rel="noopener nofollow">tailwindui.com</a> as an example is also unfair because that site is a playground of use cases so it’ll output a lot of CSS. I never did huge projects with it but all I did always ended up with a minimum CSS file.
Bottom line, I must admit Tailwind has a steeper learning curve, most part by its config file, not by the CSS itself. But your article is just a personal opinion and its subject is based on that. Nothing else.