Same Discussions Over and Over Again
This post debunks some of the arguments against using tailwindcss. I've argued about them quite often in the past. Maybe you have, too? I'll plan to just reference this article from now on. This will make my (and your?) life easier 🤪
If you are in the 'against Tailwind camp', I'm interested in valid counterarguments from your perspective. In the end of this article I will point to a con I currently think of as being somehow valid.
NOTE: Event though this post is about Tailwind the written also applie for utility first CSS frameworks in general.
The Counterarguments
These are just some statements I heared over and over again over time. I'll go thorugh them one by one after this section. They are order in descending order after the emotions coming up on my side 😅
Tailwind violates the seperation of concerns between style and markup.
Tailwind is like inline styles and they are considered bad practice.
Tailwind is huge and reduces performance. You have to setup
PurgeCSSPostCSSplugin to make it smaller.
There is a lot I have to learn upfront.
HTML looks like a mess and is bloated.
Debunking the Arguments
Now to the fun part. How can be argued against these arguments?
Violates Seperation of Concerns
Tailwind violates the seperation of concerns between style and markup.
The concercs being referred to are the markup (HTML) and the styling (CSS). People pointing to this often like to refer to CSS Zen Garden, which showcases that the look and feel of a website can be changed entirely by only changing the CSS. Yes, that is true, it is possible. How often have you changed the look and feel of your entire site without touching HTML (not talking about dark mode 😉)?
You think with something like BEM (Block Element Modifier) you have "seperated the concerns"? A card using BEM could look something like this:
<div class="card card--dark">
<img class="card__image">
<h3 class="card__heading">Heading</h3>
<div class="card__content">
<p class="card__text">Lorem Ipsum...</p>
</div>
</div>
I hope you don't want to tell me the concerns are seperated now. The markup knows about being displayed as a card. You want something looking similar, but it isn't realy a card? Maybe you are starting extending .card somehow or find a broader, more general name.
What benefits do you get by trying to completely seperate the styling from the markup? From my perspective it even is a strength of Tailwind to keep them together! Just imagine you (or somebody else) will remove the card in a few month or create a different styling for it. Will you remember to also delete the CSS? Can you delete it? Another scenario: You have a big (React) component and want to cut it into smaller pieces. Which of the CSS can (or have to be) taken to the newly created component? Strg + F will probably be your friend.
Keeping styling and markup together improves maintainability.
Another benefit of not seperating the styles from the markup: You don't have to come up with names for things. You want to change the card to be displayed as something else? You will probably change the name... It may seem like a minor thing to you, but for me it is actually one thing less to worry about.
You probably have read or heard the following quote before:
There are only two hard things in Computer Science: cache invalidation and naming things.
Read this if you have never heard about it.
There is an in depth article with the title CSS Utility Classes and "Separation of Concerns" from Adam Wathan. Read it if you are not convinced yet. It may be a little biased, beacuse Adam is the creator of Tailwind 🤪
Tailwind is Like Writing Inline Styles
Tailwind is like inline styles and they are considered bad practice.
Sorry, but you didn't get the point of Tailwind. Most probably you haven't used it all. (How are you able to argue against something you haven't really tried yourself?)
Okay, got it, there are quite a lot of 1:1 mappings between CSS properties and Tailwind classes like display: flex and the class flex. But, first of all - just being a side note - this is not true for all cases, e.g. space-y-1 (which is one of my favorites) translates into
/* CSS for Tailwinds .space-y-1 */
--tw-space-y-reverse: 0;
margin-top: calc(0.25rem * calc(1 - var(--tw-space-y-reverse)));
margin-bottom: calc(0.25rem * var(--tw-space-y-reverse));
Way more important: Tailwind is not about the translation of CSS properties into classes. It enables you to easily use (and stick to) a design system by providing a limited set of classes through the theming, which helps you to create a consistent styling more easily. style="color: #6366F1;" and class="text-indigo-500" provide the same outcome in this case, but by using inline styles you could just use a slightly off color in the next place wheareas with Tailwind you would use something like class="text-indogo-600". Yes, you could achieve something like this with CSS variables yourself, but Tailwind already provides that to you out of the box.
Tailwind Is Bad For Performance; PurgeCSS Has to Be Set Up
Tailwind is huge and reduces performance. You have to setup
PurgeCSSPostCSSplugin to make it smaller.
You are at least somehow right. Tailwind is huge without using PostCSSs PurgeCSS plugin in order to remove unused classes (about 3.5MB uncompressed). But you don't have to setup PurgeCSS and integrate it into you build step, pipeline or whatever you use, because since v1.4 this is built in. Just provide the purge option in tailwind.config.js and you are good to go.
The end result will probably be even smaller (and therefore more performant) compared to your own CSS. Chances are, when writing your own CSS, that you ship at least some unused CSS (remember the argument about seperation of concerns). Besides that you have a lot of duplicated CSS in different places instead of reusing predefined classes (I haven't measured it, but it makes sense to me. Anyone has numbers?).
⚠️ A valid painpoint regarding the purging is the fact that you have to be aware of how the purging works. You have to write purgable HTML. You can't use a class like text-$(color)-500, because PurgeCSS just works by parsing your HTML as a string. It does not run your code or interpret it in some way.
A Lot to Learn
There is a lot I have to learn upfront.
There is an upfront learning curve. But it is way flatter than you may think. The classes are very natural and consistently named. You only need to know a subset and chances are you can derive classes from your existing knowledge. There are exceptions to this: I had to look up the classes for line-height quite often (e.g. .leading-loose).
It is way harder to remember the classes of CSS frameworks like Bootstrap and strangely enough I've never heard that as an argument against it 🤷🏼♂️
HTML is a Mess
HTML looks like a mess and is bloated.
Okay, there are no arguments to fully debunk this statement. This is copied from one of my projects:
<article className="overflow-hidden rounded-lg shadow-md cursor-pointer duration-300 ease-in-out hover:scale-102">
<section className="h-full p-3 rounded-lg shadow-lg bg-gray-50">
<h3 className="mt-1 text-xl font-semibold truncate">Title</h3>
<footer className="flex items-center mt-2 space-x-2">
<!-- ... -->
</footer>
</section>
</article>
The HTML undoubtly is more cluttered 😕
BUT on the other side you don't have to switch into other files to see / adjust the styling. And how much of a deal is it with syntax highlighting? You will still be able to have an overview over the HTML elements due to a different color. In the end this is something you will get used to.
Valid Cons
Even though you probably by now have noticed that I am somehow a fanboy, I am also a quite sceptical and analytical person in general. There are seldom things without any tradeoffs. It is always about trade-offs.
Please let me know counterarguments I haven't mentioned.
I also have one myself: Compared to component libraries like Chakra UI (which I absolutly love - it has a very Tailwind-like API), you have to write things from scratch. Common building blocks like buttons, date pickers, modals and inputs are hard to get right (especially considering a11y). So Tailwind initially has a burden to get up to speed. BUT. Firstly, you can reuse what you have written before and therefore it gets better. And secondly, this is where Tailwind UI and Headless UI come into play. They provide you easily adjustable building blocks.
Conclusion
I love Tailwind ❤️ There are reasons why it is getting very popular. You should try it out if you haven't already. And if you still have concerns after a while you are in a position to argue against it. (Again: Don't argue against things without at least having tried it out.)
Happy to hear your feedback. Are you using Tailwind? Not? Why not?
Top comments (3)
I think most people that argue and try to depreciate Tailwind are either
1) purely theorethical in the long-term maintenance of a project
2) never worked in a project with more than one FED for over a year
In both cases it boils down to being unexperienced and they just need to live through the pain of a css maintenance on their own, until then, they will try to convince the world that some utopian vision about "concerns" is more important than being able to work without rewriting the frontend every 2 years or spending 10 hours a month solving css conflicts. They will learn, CSS and time is a very good teacher of pragmatic programming :)
Agree.
You will experience some things only by trying it. I mean it's more obvious the HTML looks somehow bloated then something like the maintanability over time being increased.
Well, bloat in html by adding classes is far easier to maintain in a team than a file of global css classes. ;) CSS being global is the worst thing about the whole environment, and Tailwind fixes that issue without adding 100 different languages, dependencies and doesnt force anyone to use some weird frameworks to achieve good performance - its by default.