I see way too many articles about why TailwindCSS is bad, or wrong, or bloated, or [insert-your-negative-adjective-here]. Absolutely, you should follow the rule "Horses for courses"—use the right tool for the right job. But the majority of these articles (that I've read) seem to repeat the same anti-utility-CSS talking points such as "HTML bloat" and "repetition is bad".
Let's respond to one such article, by @gravy59. You should read their original post in full.
🚨 Before we jump in
Please read this with the intention that it was written, as a rebuttal to the original post. The goal here is to provide devs (both starting-out and experienced) with multiple views on a topic, so they can make more informed decisions about the technologies and practices they choose to invest their time in.
🤦♂️ Atomic classes are essentially inline styles
Tailwind's config file allows you to create any number of CSS properties, and their new JIT arbitrary values are essentially inline css
This is false. Arbitrary values (and even arbitrary properties and variants, for that matter) are superior to inline styles in that you can use modifiers such as
hover: or even media queries, all without having to leave your HTML. Is it recommended that you use arbitrary values/properties/variants liberally? No—you should stick with your preconfigured design system wherever possible. This is a niche tool for things such as unique design elements.
This can sometimes result in massive, bloated class names that are not that better than inline styles.
Again, as above, it is unfair to conflate inline styles with class names. And if you're struggling to read your TailwindCSS class names, make sure you have the Prettier class sorting extension installed.
🤦♂️ BEM is a better choice for reusable components
Tailwind isn't as friendly to reusable components compared to something like BEM.
I would argue that BEM works against reusable components, in that at its core you are required to name "things"; arguably one of the most difficult and time consuming things a dev might have to do. Unless you have thought through every possible abstraction and mutation of your technical requirements, you're going to run into cascading and inheritance issues.
Moreover, BEM can lead to premature abstraction and the creation of unique single-use modifier classes to target edge cases. Sarah Dayan has a great write up on this.
🤦♂️ Repetition is bad
Their solutions are flimsy at best. They recommend that you
A) Use a framework, which not all developers want to do, or
B) extract styles with their @apply directive, which do anything about the problem Tailwind was intended to solve.
Don't forget the very first solution in their documentation: Using editor and language features. IDE tools such as multi-cursor editing and language template loops are powerful and quick enough to deal with repetition. Selecting the class and pressing Cmd+D or Ctrl+D a few times on your keyboard is super simple, effective and, in most cases, all you need:
🤦♂️ Avoid HTML file-size bloat at all costs
The first solution works fine from a workflow standpoint, but at compile time you're still left with bloated class names (even if Tailwind purges unused css) that in some cases can balloon file sizes.
This is another one of those myths that keeps circling the drain, but threatens to linger on forever more. Sarah covers the "HTML class names bloat" myth succinctly in her article. The TL;DR version is:
- Gzip was made to handle duplicate strings.
- Trimming your HTML classes will make little to no difference in your final request size.
- "HTML bloat" doesn't matter, but "CSS bloat" does.
📣 Don't take my word for it
I would highly recommend you subscribe to and check out Theo's content on YouTube. Theo is a massive advocate for TailwindCSS, and for good reason.
Below is just one of his videos debunking TailwindCSS myths and providing his sound reasoning for continuing to use it to implement his design systems:
👍 At the end of the day, use what works
I've said it before and I'll say it again: "Horses for courses" 🏇
Sometimes, TailwindCSS is going to be a great tool for the job, maybe even the best tool. Other times, plain CSS is going to do the trick nicely, or perhaps a CSS superset like SCSS. Or maybe Styled Components are going to deliver greater "bang for buck", given your project's technical requirements.
Ultimately, use what works for you, and for your project. But let's make sure we're not misrepresenting the tools we choose not to use.
Top comments (24)
It's a tool so it's nice, but you don't NEED tailwind. A frontend dev NEEDS to know CSS, but Tailwind isn't something you need is all.
It's nice, but so is Shoelace, so was Bootstrap once, and some people think drag and drop website builders are nice...
In the end, the more experience you have writing code, the less of these things you use because no matter how you slice it the tools have to compile or process your modified code to in the end generate the flat code anyway. If you can write the flat CSS on your own you do not need the tools. That's all.
In the end it's personal preference that wins over all. Everyone codes using tools or not using tools because THAT is how they like to code.
The real question is, how many of us stop and try something new every once in a while just to give it an honest chance.
Absolutely agree that you don't need to use TailwindCSS, but you definitely need to know CSS.
A great thing I find about TailwindCSS is that, because the rules are atomic and represent 1:1 property-to-value pairings, you grow your understanding of CSS while simply using TailwindCSS: you begin to understand what
flex justify-between items-centeris going to do, and the specific CSS properties and values that work behind it.
You're right, your code is always going to be transpiled down to the most commonly-interpretted denominator. But I don't feel that's a reason not to use TailwindCSS.
☝️ This right here is gold—couldn't have said it better myself, mate!
Hey Dan, so I've tried Tailwind [and bootstrap, and shoelace, and some others i can't recall right now], a couple of years ago. To me they all just looked like "another bootstrap with some new bells and whistles".
My main "con" with these things is the "I need to learn this tool's terminology for CSS when i already know how to write CSS rules to build this stuff", so personally it's just never been a need. I learned to write CSS long before these tools came about and i kept up with CSS3 once that finally arrived and was supported.
Now, you just said about the transpiling thing, that you "don't feel that's a reason NOT to use TailwindCSS", however to me it's never been about finding reasons NOT TO, but to find reasons i SHOULD :)
You NEED TailwindCSS if you want your web app load fast. And it's not "another bootstrap with some new bells and whistles". If you tried it and felt so, probaly because you were doing it wrong.
No, you do not ever NEED any CSS library or preprocessor or any of that stuff, if you know how to write it to perform well.
You can choose to use them if you want to, or if you feel you have to, but you never NEED to.
Examples of my work to back this up.
indiegameshowcase.org [a vanilla js site fully custom css, runs damn fast
with a $10/mo DO server and DO apps frontend]
webnuz.com [PHP flat html cache shows 200-300 articles on homepage daily, updated hourly, frankly has little css]
I figured chatGPT would be friendlier about this:
ChatGPT’s facts don’t care about your feelings 🤪🥲🤖
Glad to see AI agrees with me 😅
People need to learn how to make re-useable components. I love tailwind and it saves me so much time. One of the topics you mentioned is repetition.
That nav bar can be turned into one dynamic element where we can store our paths within an array of strings and simply loop through it with one element.
I've been wanting to create an article on how to use tailwind properly. I think I might just do that.
I hear you! 🙌
Finding and (hopefully not prematurely) abstracting patterns into reusable components is one of my coding joys; it’s like connecting an edge-piece on a puzzle—it builds upon the whole and creates something you can anchor to and build from.
Can’t wait to read your article, I’m sure it’ll be great! Maybe drop a link to it in the comments so we can all enjoy it. 😊
Do it! And can you add an example of how to direct the user to a different page if they're on a mobile device by checking against the defined sm breakpoint in your tailwind config? And also how you would go about creating a while label app where the user picks the theme color and background image to fit their company?
Comencé "odiando" tailwindcss hasta que me puse a leer muy en profundidad su documentacion y cuando arreglaron el problema que tenian con la interpolacion de clases lo termine amando y hoy lo uso a diario. Como decis es fundamental reutilizar componentes para evitar ver esas clases largas y tener un clean-code. Larga vida a tailwind!
An abstraction layer can't satisfy everyone. Also, unlike most other frameworks and methods, Tailwind helps you learn CSS. You still need to think and know CSS if you want to use Tailwind. Meaning CSS will click more as you write more Tailwind. IMO it is the best option if you want flexibility and speed without the performance tax.
Also, it feels like a lot of Tailwind nay sayers haven't used it. They might have seen some videos and some code. Cos a lot of the points they make a lot of the time was wrong. Like arbitrary property and values for instance.
Link to my article if anyone is interested - Explaining what a good abstraction layer is with Tailwind CSS.
Tailwind is not meant for those who want to skip CSS basics, which can be problematic with some demos trying to market it as a magic stick. The tool aims to speed TTM (time to market) and provide reusable components.
Really cool to build dashboard templates (I'm not saying it's the only usage), for example.
100% yes to all of this. Gotta have solid foundational knowledge of HTML/CSS before sticking any library/framework/tooling on top of it. Otherwise you just end up grinding to a halt with every roadblock you inevitably hit.
There are no shortcuts to doing things well.
This is a very well written article! Thanks for taking the time to write this. I have one point to make: editor & language features are great but - for me - difficult to work with.
First of all, I see zero hate in the article you're replying to. It's really hard to stay objective while reading your post, which claims there's so much hate. Just that someone does not like the technology you like does not mean they hate it. Or you.
After all, most of the points raised both in your and original article are a matter of taste.
That being said, I'm recently finding Tailwind useful for some use cases. Unsurprisingly, the ones for which it was designed, even though it won't openly say it.
Appreciate your insights, @katafrakt.
Perhaps my wording choice for the title of the article was insufficient, though the rhyming was alluring. I had hoped that readers would infer from the opening paragraph that I was making a generalisation about the growing number of unjustly negative "reviews" of TailwindCSS. "Hate" is certainly a strong word (and in some cases, justified in its use), however I can appreciate it may be too strong for some tastes given the context. Open to your suggestions for change.
I don't disagree, however the key difference between both the original article and my own is that the former argued that "TailwindCSS is insufficient because X and Y are true", however the latter attempts to rebut that "X and Y are factually incorrect and/or incomplete, therefore giving readers a misinformed view of TailwindCSS and unfairly colouring their judgement of it".
I don't think I'm getting the point you're making here. "Hostile" isn't the word I would use, but I assume you are referring to tweets such as this:
If there was ever a reason to be "negative" towards their own
@applyfeature, it would be because of the unnecessary complexities it brings to the codebase and the high cost to resolve those issues:
I don't see anything wrong with a company adding a feature to their product that, at the time made perfect sense, only to realise later down the track that they were wrong. It's great that they are constantly experimenting with new ideas, it's what moves us all forwards, together.
I'm glad that you're finding it useful, for some use cases. But that's the point I'm trying to make—I don't want everyone to use TailwindCSS because I think it's great; I simply want everyone to have complete and accurate information about TailwindCSS, so they can make informed decisions about whether or not it suits their project's needs.
Thanks again for contributing to the discussion! 😊🙇♂️
Appreciate your kind words! 😊🙇♂️
I must be old but I’ve got fatigue for anything like tailwind or it’s successors I gave up sass and the likes to use css like I did many years ago, but I’m smarter about it, that’s what stops me making a mess, I think if had to use any tooling I’d just use post css that’s it.
I won't recommend Tailwind to codenewbies that are learning frontend development to get a job, but if you already have a job and want to try and test Tailwind then sure, go for it!
When working professionally though, I just prefer CSS-in-JS like Styled-Components, which helps in every single aspect I could think of:
And last but not least, If you care about performance related to SEO, then you should not be using React, Angular, Vue, svelte... without SSR. If you do so, it must be that you don't need technical SEO anyways (corporate/private Apps) so you just assume the extra runtime cost.
If you are developing a web portal for end users and you want to develop properly the technical SEO side, then you just use Next JS or SSR on any other framework. The good news is that Styled-Components supports concurrent SSR, which will keep your App blazing fast and SEO friendly.
Hi @danwalsh ,
I have just posted Best Practices for Utility-First CSS right now and saw the article you are referring to.
I agree with you.
A lot of those issues come from inexperience (not understanding the difference between class and style attribute, not understanding the tool/framework), laziness (writing everything without thinking into class attribute and blaming the framework), and simple ignorance, that there is a different way to write CSS.
I think, that it should also be mentioned, that utilities solve a lot of other problems:
There is simply a reason why big companies like Medium.com and Facebook use it.
Facebook even wrote an article about it engineering.fb.com/2020/05/08/web/....
Medium pushed the optimization even further and Stylify inherited the optimization algorithm for mangling selectors and splitting CSS.
But I understand, there are people that will simply not like the utility-first CSS approach and will write it manually.
The issue is this: you're essentially learning a language on top of a language (css). Normally there's no problem with that, except in this case tailwind severely limits what you can do, because all its utility classes are defined at compile time. This means you cannot access any values like the theme color or the defined spacing unit or the sm breakpoint value in your js code, which sucks. It also means you cannot reflect any dynamic values in your utility classes, like when you have to make a white label app. The only way to do that with tailwind is to use css variables and manipulate those using js code, which is just a bug waiting to happen. CSS-in-js solutions like emotion solve all these problems for you, by not letting them happen in the first place. But if you're really convinced that utility classes are the way to go, you can easily write a script to generate utility classes with emotion 😅