Disclaimer: This article is my version of Tailwind CSS: Adds complexity, does nothing. I respect the original author’s opinions, but I think there’s a better way to criticize Tailwind CSS. Here goes.
If you work in the front-end, you’ve probably heard a lot about Tailwind CSS, a CSS framework, much like Bootstrap. Much unlike Bootstrap, however, Tailwind takes a different approach – it is almost exclusively “utility classes”.
And it might not be for everyone.
Before we start, let me try to explain what a utility class is. Let’s say that you have many components, and many of them need to have the CSS declaration display: flex;. Instead of writing that over and over in your CSS, you create a class called flex:
.flex {
display: flex;
}
Then, in every component that needs to be flexed, you add that flex class.
This is not a bad thing. I have written and used utility classes a great deal myself, especially when I’m writing CSS without the aid of CSS-in-JS solutions or a preprocessor like Sass/SCSS.
What Tailwind does is take that concept to the extreme, with the idea being that you almost never have to write CSS, you just add different classes to your HTML based on what styles you need to apply.
Which is an interesting choice, because...
This is embracing inline styles
Back before stylesheets were a thing, HTML had elements such as <font> and <center> to apply some basic styles directly in the markup, much like the style attribute that came along with CSS. But while inline styles are still a thing nowadays, we know better than to use them since we have stylesheets now, which let us “separate concerns”: HTML is for content and structure, CSS is for presentation.
However, Tailwind doesn’t adhere to that idea, and goes back to the 90’s way of mixing content and presentation in the same file. So why not just use inline styles then? Writing <div class="flex">foo</div> has the same exact effect as writing <div style="display: flex;">foo</div>. Well, it turns out there are a couple reasons, as outlined in the Tailwind documentation. Notably, inline styles don’t support media queries or pseudo-class selectors such as :hover or :focus, so you can’t have responsive or dynamic styles with them. Building a whole app or website with inline styles would be impossible for that reason alone, unless you decide to pretend that mobile devices don’t exist. If that’s not reason enough, Tailwind makes a strong argument for “designing with constraints”:
Using inline styles, every value is a magic number. With utilities, you're choosing styles from a predefined design system, which makes it much easier to build visually consistent UIs.
Indeed, Tailwind’s theme configuration is one of its greatest strengths. It prevents your stylesheet from containing 69 unique font sizes and some background colors that are different but so similar that they should clearly be the same (e.g. #ffe42e and #ffe322). It also helps developers design faster and be more confident that they’re not introducing visual inconsistencies.
But even though Tailwind improves a lot on inline styles, it still embraces their philosophy and suggests that it’s totally fine – even desirable – to mingle presentation with content. Consequently, some of the arguments that you could make against using inline styles are also arguments against using Tailwind. I know it seems a bit lazy to rehash other users’ criticisms of inline styles to explain why Tailwind might not be for you, but let’s do it anyway:
It’s WET, not DRY
When you want to change your site’s styling in a major way, if you’ve used utility classes, you need to go through each use of those utility classes – that is, every component – and visually determine what needs to be updated. For example, let’s say that your company’s primary color is blue. You’ll have lots of blue stuff in your website, marked with classes like text-blue-700 or bg-blue-500, which represent different shades of blue. And that’s fine until your company decides to rebrand, and all of the buttons on the site – but only the buttons – need to be red.
If you were using regular old CSS, you would probably have a class called button. You would just go into that class in your CSS and change a single line: background-color: red;. Any element that uses that class definition would now be red.
Instead, with Tailwind, you have to go through each component and manually change bg-blue-500 to bg-red-500. And with 1000 edits comes 1000 opportunities to introduce a bug. It is almost a textbook definition of why the DRY principle is in place.
That is, unless you bring back the abstraction that you lost by replacing button with a bunch of utility classes in your HTML. In my experience, Tailwind works best if anything that used to be a “CSS component” (like the button class) is made a “template component” (a reusable file that includes both the markup and the styling). That makes sense when you think about it, and you end up removing even more duplication: not just the Tailwind classes which now live in a single file instead of 1000, but any attribute (think ARIA) or child element of the component (think button__icon). Turns out your code’s DRYness is up to you, not up to Tailwind!
The above assumes that you’re using some kind of component library (e.g. React, Vue, Svelte, etc.) or templating language that supports partials (Twig, Blade, PHP, etc.). If you’re not, or if you find that it would be cumbersome to create a component or partial for a simple button, that’s totally fine. You don’t have to change your abstraction model, you can still use CSS itself as your “component layer”. That’s where Tailwind’s @apply feature comes in handy: you keep your button class, but instead of writing background-color: red;, you write @apply bg-red-500;. That way, you’re still using the theme configuration instead of a hard-coded (magic) value. This is similar to what you can do with preprocessors or CSS variables, but using the Tailwind API.
HTML is traditionally concerned with structure, not styling
People talk about separation of concerns a lot in development. CSS Modules (and especially .vue files) have done a lot to dispel the notion that you need to segregate structure, behavior, and style of each building block of your site in separate folders, but there is something to be said for separating concerns. That is, each part of your code should be “loosely coupled and highly cohesive.”
In other words, your HTML (structure syntax) shouldn’t have information about what the styles should be; it should only contain information about the structure of the page. Indeed, the ultimate reason for the invention of CSS, the whole point of the entire enterprise of CSS... was specifically so that you could separate content from presentation.
And yet, Tailwind embraces the idea of inline styles, which goes against that whole concept. Why is that? Adam Wathan, the author of Tailwind, has written an article about how separation of concerns is “a straw man” and we should instead think of it in terms of “dependency direction”. It’s a long read, but it’s worth it to understand where Tailwind comes from.
It turns out Tailwind, like most CSS frameworks, is targeted towards developers who prefer writing HTML that depends on CSS, over CSS that depends on HTML. Adam mentions that both approaches are perfectly valid, and it comes down to “what’s more important to you in a specific context”. Tailwind takes the first approach, and goes as far as it can with it. As a result, developers can build custom UIs right in the HTML because the CSS provides all the necessary building blocks.
When we write code, we write it for two audiences: the first is the computer itself, which doesn’t care how the code looks so long as it runs, and the other is our fellow programmers. The easier it is for them to quickly identify what parts of your program are and how they interrelate, the more quickly they can fix bugs, add features, and bring value to the organization. Tailwind makes it easy not only to build UIs without switching context, but also to understand what each element looks like at a glance, since the styles are right there in the same file.
The flip side of losing “semantic” class names in favor of utility classes is that it becomes not as obvious what a given piece of HTML represents in terms of content. Thankfully, that is easily mitigated by using well-named components, or adding comments or even classes that do nothing but describe what an element is (as the first class, so it’s not lost in the sea of utilities, obviously).
It’s hard to read at first
If you look at some HTML with Tailwind in it, you might say to yourself that the HTML looks “busy” or even “ugly.” That's true, but some say you get used to it.
The real catch is that you have to learn all these classes before you can be productive with it, even if you know CSS really well. Tailwind is full of semantically obscure abbreviations such as w for width and h for height. The framework tries to find a balance between terseness and expressiveness, but it can definitely feel cryptic at first.
Here's an example from Aleksandr Hovhannisyan.
This Tailwind code:
<div class="w-4 h-4 rounded text-white bg-black py-1 px-2 m-1 text-sm md:w-8 md:h-8 md:rounded-md md:text-base lg:w-12 lg:h-12 lg:rounded-lg lg:text-lg">
Yikes.
</div>
could be expressed as:
<style>
.thing {
width: 1rem;
height: 1rem;
color: white;
background-color: black;
padding: 0.25rem 0.5rem;
margin: 0.25rem;
border-radius: 0.25rem;
font-size: 0.875rem;
line-height: 1.25rem;
}
@media screen and (min-width: 768px) {
.thing {
width: 2rem;
height: 2rem;
border-radius: 0.375rem;
font-size: 1rem;
line-height: 1.5rem;
}
}
@media screen and (min-width: 1024px) {
.thing {
width: 3rem;
height: 3rem;
border-radius: 0.5rem;
font-size: 1.125rem;
line-height: 1.75rem;
}
}
</style>
<div class="thing">Yikes.</div>
As you can see, there are pros and cons to each approach. The second example is much more expressive (especially if you don’t know Tailwind), but it’s a lot more code, and the styles are separate from the element they are affecting. The Tailwind code, on the other hand, is short and you don’t need to open another file to understand how it’s styled. You may find it cryptic, but after just a couple days of using it, you should be able to decipher it effortlessly.
It’s worth noting that Tailwind classes are arranged horizontally, while the CSS is written vertically. The wider text is, the harder it is for a reader’s eyes to jump to the next line, and the harder it is to find the one particular word you’re looking for in a wall of horizontal text. That’s part of the reason why Tailwind classes are terse (in addition to typing speed and file size). Note that there are different ways to mitigate lines getting too long (enabling wrapping in your IDE, adding line breaks, using @apply selectively, etc.), but it is a potential issue to be aware of.
Again, this is a matter of preference. Tailwind might be for you, or it might not, but it’s hard to know without giving it a real try.
You lose a lot of the features built into standard CSS
...if you insist on not using any custom CSS. But realistically, most Tailwind projects have some custom CSS, which is totally fine – Tailwind itself is a PostCSS plugin, meaning it runs on CSS source files, not instead of.
So if you want some specific styling rules, for instance to add some margin between p tags inside a description class, you’ll have to write custom CSS, though nothing prevents you from using @apply:
.description p + p {
@apply mt-4;
}
Note that there are also lots of plugins, including some official ones such as Typography and Forms, for extending Tailwind’s core functionality.
It solves a problem that you may not have encountered
We’re all different. We work on different projects, have different methodologies, use different tools. One tool cannot claim to solve a problem that everyone is having. The best it can do is exist for the people who are experiencing the specific problem it was built to solve, and provide great documentation and other resources to learn about how it can make your work, or your life, easier.
Tailwind does just that. It’s not for everyone. If you’ve read Adam Wathan’s CSS Utility Classes and "Separation of Concerns" article and couldn’t relate, I’m happy to tell you that Tailwind is probably not for you. If writing custom CSS is what you enjoy the most, or you need to apply different stylesheets to the same HTML to radically change how it looks, Tailwind is not for you. That’s OK! Go build great things with your favorite tools.
Nothing is perfect
Something else will come along eventually, solving some of Tailwind’s problems, and maybe it will introduce new problems that we can’t even imagine. Maybe it will be a core web technology, who knows. But in the meantime, if you decide that Tailwind is for you or your team, it’s going to provide a great developer experience with some of the best documentation I’ve ever seen in an open source project, your CSS is going to be as small as ever, and after a while, you might just wonder how you ever did CSS any other way.
Top comments (13)
I don't agree with the color example you took. If you're building using Tailwind at scale, You would define your colors as primary, secondary, warning, success, etc., and use that instead of directly using Tailwind's color palette. Something like
bg-primary-500would be used and the color would be changed.I've been using TailwindCSS for a long time and I absolutely love it. I have no complaints whatsoever. It makes my CSS files so much more smaller and makes websites load even faster. It makes development fast because I don't have to keep switching between CSS and Templates Files. Also in a case where you need different selectors, you can always write Custom CSS.
You mentioned TailwindCSS being well suited for component architecture. TailwindCSS was made to be used in a production environment. And in production, you are expected to use a component-based design system. And even if you're doing small projects, you should always prefer a component-based system.
Re: colors, absolutely. I meant to include that point in the article but forgot about it. Thank you!
Nice article. Although I haven't tried tailwind but you've given me enough reason why I should keep postponing it. I can't imagine writing html with inline cryptic styles that will muddle up what is meant to be a structured page, Am just imagining how crazy debugging will be when you have hundreds lines of code.
I mean, you can use "@apply" to apply tailwind styles from css.
I find tailwind classes easier to memorize that normal css, but that's just my experience.
tailwindcss.com/docs/extracting-co...
Having read your reference article when it was released, I'm happy to now read a more sophisticated view on the subject.
In any biggger team project, you would always consider different technologies, comparing their pros and cons before making a decision. Tailwind has many flaws, but it might proof to be just the productivity tool you've been looking for. Imho, instead of dragging tailwind through the dirt, your article provides guidance for a substantiated statement. Kudos, well done, I'd be happy to read more of such posts.
This is a very good way to put things into perspective. I agree, that Tailwind has its place in the web dev space, and it does solve some specific problems, and that it's not an exception to the rule that no single solution solves all possible problems.
That is why the open source space is such a vast resource of various solutions for widely different problems.
Really interesting article and thank you very much for sharing it. I agree with the other readers that said this is not an article meant to place Tailwind in a bad light. Just out of curiosity @benface can you share what was the framework that you actually used for your last 2-3 projects (or no framework of course)? Not asking which one you prefer just which one you had to work with or you chose to work with. Thank you, love your writing style.
Tailwind. :) I’ve been using it since 2017. I find that the pros vastly outweigh the cons. I've also used Bootstrap and no framework on some projects, but it was not my choice and it was definitely hard after using Tailwind. Thanks for your comment!
:) thank you very much for your reply and hope to see more articles from you
Interesting stuff! This (and Adam Wathan's article in particular) relates a little bit to a post I just wrote on the idea of first-class whitespace - similar themes around what to put in markup vs CSS, and whether accepted CSS patterns are actually the best for code organisation - especially now that we have component frameworks.
dev.to/wdpdfpjrwkrszhs/css-margins...
As developers and engineers and architects we need to stop doing this to ourself we need to stop trying to find a way to make our lives more complex with obscure and hard to read and hard to maintain things. Remember how we told everybody for years to use a CDN and to stop doing online styling because it was faster and saved bandwidth from bloat? It seems like somebody thought to give themselves a hackathon challenge to try to bring it back and give it some form of justification.
Complexity is not sophistication
I can't disagree more with this article!
Semantic css is a way to create something totally unmaintainable, while utility classes give you option to easily change and target many things at once. This is especially important when working in the bigger teams and on many projects where things have to be unified... Also didn't you know that you can combine tailwind/bootstrap/whatever with some custom css? 😅
Some comments may only be visible to logged-in visitors. Sign in to view all comments.