TailwindCSS is great; why so much hate?
Tags: tailwindcss, css, webdev, rebuttal
Published: 2023-02-02 00:35:36

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](https://dev.to/gravy59). You should read their [original post](https://dev.to/gravy59/tailwind-css-a-critique-2hfh) 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](https://tailwindcss.com/docs/adding-custom-styles#using-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](https://tailwindcss.com/blog/automatic-class-sorting-with-prettier) 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](https://www.freecodecamp.org/news/in-defense-of-utility-first-css-4f406acee6fb/#-bem-is-enough-).

## 🤦‍♂️ 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](https://tailwindcss.com/docs/reusing-styles#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 <kbd>Cmd+D</kbd> or <kbd>Ctrl+D</kbd> a few times on your keyboard is super simple, effective and, in most cases, all you need:

![A code IDE demonstrating how to quickly edit class names using multi-cursor selection](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/4hjo7r92p176yjfrevob.gif)

## 🤦‍♂️ 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](https://www.freecodecamp.org/news/in-defense-of-utility-first-css-4f406acee6fb/#-it-bloats-the-html-). 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](https://dev.to/t3dotgg) content on [YouTube](https://www.youtube.com/@t3dotgg). 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:

{% embed https://www.youtube.com/embed/QBajvZaWLXs %}

## 👍 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.

Peace 🕊️