DEV Community

Cover image for TailwindCSS is great; why so much hate?
Dan Walsh
Dan Walsh

Posted on

TailwindCSS is great; why so much hate?

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:

A code IDE demonstrating how to quickly edit class names using multi-cursor selection

🤦‍♂️ 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.

Peace 🕊️

Latest comments (32)

Collapse
 
benglasser profile image
Ben Glasser

I hate Tailwind because it screws up my workflow.

Call me "old school" but part of my workflow entails fudging things around on the page using tools like the inspector and overlays like "pixel perfect". I use the inspector to highlight an element and then fudge the css numbers until it's perfect. Then I transpose all the values I need all at once. One thing I do a lot of is using the arrow keys to fudge padding, margins, etc. This is impossible with tailwind.

In fact, because tailwind optimizes its contribution to bundle size by removing unused tailwind classes I can't fudge the tailwind classes around in the inspector at all unless the class I want to experiment with is being used somewhere else on the page. This results in a shit ton of window switching between the browser and my text editor so that the watcher can pick up changes and reload the css.

Collapse
 
mendrik profile image
Andreas Herd • Edited

Previously I would write a reusable component ActionList and do some instances of it like

const Breadcrumbs = styled(ActionList)`..looks like breadcrumbs...`;  
const Menu = styled(ActionList)`...looks like menu links...`;  
Enter fullscreen mode Exit fullscreen mode

With tailwind I have to replicate ActionList and clutter each markup-tag there with different classNames. I don't understand why people use tailwind.

  • You add visual clutter to oftentimes already unreadable JSX
  • You cannot reuse components in the classical sense
  • What used to be previously simple CSS organized by nesting, media queries and pseudo selectors, becomes now a verbose mess of prefixed tags, where it's hard to see which style-tokens belong together.
Collapse
 
kilometers profile image
Miles Baird

Can you believe this article taught me ⌘ + D

Collapse
 
sweeperq profile image
Sam Kimmel

It doesn't seem terrible for component-based apps where you create something like an Input control and apply styles to it. But honestly, I feel dirty using it because 15 years ago we were told inline styles were bad and to use stylesheets. Tailwind mostly feels like inline styles.

I find it somewhat comical when people say, "you don't have to create magical class names and remember what they mean." No, instead I have to Google how to apply a line-height because they named the related classes "leading-[value]".

I don't like how tailwind removes all styling for everything by default. If I have to apply tailwindcss classes on everything anyway, why reset the default colors, sizes, and margins on things? I can just override them with the utility classes. I'm not going to put "mb-3" on every heading, paragraph, list, etc. So then I end up creating a default stylesheet anyway and use "@apply" to use the tailwind utility classes instead of vanilla CSS.

My personal opinion is that a good way to utilize tailwind is to create a default stylesheet with your preferred site-wide styles, add a few classes common things like inputs, buttons, labels, etc, then use the utility classes for the layouts and one-offs.

Collapse
 
danwalsh profile image
Dan Walsh

You might find it feels like inline styles, but that doesn't mean they are inline styles. TailwindCSS is a generated collection of atomic classes with low specificity. Along with the power of class names comes the ability to leverage media queries, pseudo-classes and pseudo-elements, all of which are configured in a central location and then tree-shaken during the build. None of those benefits apply to inline styles. Arindam Majumder has a great post further breaking down the differences.

When people are arguing that when using TailwindCSS "you don't have to create and remember magical class names", they are referring to class names like card or subtitle or promo-box-feature. It is impossible to infer what styling these classes might apply without either applying them to an element for inspection, or finding their definitions with your source code (and of course, that is to say that the developer values such a requirement). Additionally, custom classes often have significant overlap (e.g. they all might apply display: block; line-height: 1.5; font-weight: semibold;), bloating the CSS bundle.

You are correct in that TailwindCSS does not intentionally line-up their utility names with CSS properties (as in your example of leading vs line-height) which, I agree, takes some learning. Thankfully, their documentation is exceptional, and a quick search for "line-height" takes you straight to the right page. After working with TailwindCSS, you can pretty readily work between multiple projects that use it; given they all share the same utility names, you can rapidly develop your frontend UI using familiar class names.

TailwindCSS "resets" the styling of all elements using what they call "Preflight", which is an extension of modern-normalize. You can read more about it in their documentation, but the notion of "CSS resets" is nothing new. And of course, you can easily disable Preflight in your TailwindCSS config.

Certainly, one way to handle spacing for elements like headings and paragraphs is to add margin classes (such as mt-3 to each element), and a great solution to target them all (as you pointed out) is to add something like this to your main CSS file:

h1, h2, h3 {
    @apply mt-3;
}
Enter fullscreen mode Exit fullscreen mode

Or, depending on your project's requirements, you could choose to leverage the official @tailwindcss/typography plugin which applies an opinionated set of styles for WYSIWYG content, including font-size relative spacing. This plugin is also configurable, allowing you to leverage many of the plugins styles while also tailoring it to your project's design.

Just be careful not to overuse the @apply syntax as it can lead to premature abstractions and costly bug fixes. Even the author Adam Wathan has publicly regretted implementing the feature.

At the end of the day, none of this is to say that you cannot use both TailwindCSS together with custom class names to build your project. It might even be the most effective way to do it, based on your needs and your team.

I hope that clears up some of the issues you've experienced, and perhaps convinces you to take another look at TailwindCSS through a fresh perspective.

Peace 🕊️

Collapse
 
unsungnovelty profile image
Nikhil • Edited

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.

Collapse
 
joelbonetr profile image
JoelBonetR 🥇 • Edited

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:

  • Everything's a component, which is nice to enforce reusability.
  • You use actual CSS (optionally SCSS), which "everyone" knows (the standard).
  • Modifying styles through presentation logic (out of CSS API) has never been so easy and clean.
  • You can actually unit-test your styled-components.

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.

Collapse
 
katafrakt profile image
Paweł Świątkowski

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.

Second, the counterarguments seem to mostly make the same mistake as Tailwind's authors made: forgetting that webdev is not only JavaScript with JSX. Most of the optimizations and workarounds like "use this Prettier plugin" won't work in these cases. I see it as a fundamental flaw in Tailwind, especially given their openly hostile stance towards using @apply.

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.

Collapse
 
danwalsh profile image
Dan Walsh

Appreciate your insights, @katafrakt.

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.

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.


After all, most of the points raised both in your and original article are a matter of taste.

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".


Second, the counterarguments seem to mostly make the same mistake as Tailwind's authors made: forgetting that webdev is not only JavaScript with JSX.

Can you please explain how I (and TailwindCSS's author, @adamwathan) are "forgetting that webdev is not only JavaScript with JSX"? A cursory glance at the documentation will show you that TailwindCSS supports several tools and technologies, including PHP and Ruby on Rails. Moreover, TailwindCSS is a Node application, it's inherently tied to JavaScript, however this does not prevent you from using it with your own stack.


Most of the optimizations and workarounds like "use this Prettier plugin" won't work in these cases.

Can you please provide some examples? Prettier itself is "JavaScript with JSX" agnostic and supports many languages, IDEs and tools.


I see it as a fundamental flaw in Tailwind, especially given their openly hostile stance towards using @apply.

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 @apply feature, 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.


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.

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! 😊🙇‍♂️

Collapse
 
brense profile image
Rense Bakker

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 😅

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

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.

Collapse
 
po0q profile image
pO0q 🦄

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.

Collapse
 
danwalsh profile image
Dan Walsh

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.

Collapse
 
machy8 profile image
Vladimír Macháček • Edited

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:

  • CSS splitting
  • Removing unused CSS
  • It solves the CSS specificity problems
  • Decreasing the headaches of selectors naming
  • It easily allows to style dynamicaly generated elements that simply are only at one page (which would be difficult to name and link the CSS for it)
  • Decreases the amount of CSS files. A simple blog has like 10 files, larger projects have hundreds and it's not an easy task to maintain that

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.

Image description

But I understand, there are people that will simply not like the utility-first CSS approach and will write it manually.

Collapse
 
Sloan, the sloth mascot
Comment deleted
Collapse
 
danwalsh profile image
Dan Walsh

Appreciate your kind words! 😊🙇‍♂️

Collapse
 
cleveroscar profile image
Oscar Ortiz

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.

Collapse
 
baash005 profile image
david

What I can't understand is how it saves you time. Typing out the raw css does not seem to take any extra effort.

Inline css would accomplish the same thing, but without the very thin abstraction. A thin abstraction that often requires you know the css you're looking for anyway..

font-bold => font-weight: bold;
px-3 py-2 => padding: 2px 3px;
...

Collapse
 
ipapoutsidis profile image
Ilias Papoutsidis

It does when you are starting built a app or a web site

Collapse
 
baash005 profile image
david

I'll go one further, and 100% not something I'd expect.
h-20 => height: 5rem.

Collapse
 
chrisbarrio profile image
Christian Barrionuevo

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!

Collapse
 
brense profile image
Rense Bakker

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?

Collapse
 
danwalsh profile image
Dan Walsh

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. 😊

Collapse
 
gravy59 profile image
Gravy59

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.

Collapse
 
ravavyr profile image
Ravavyr

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.

Collapse
 
danwalsh profile image
Dan Walsh

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-center is 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.

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.

☝️ This right here is gold—couldn't have said it better myself, mate!

Collapse
 
ravavyr profile image
Ravavyr

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 :)

Thread Thread
 
mangor1no profile image
Mangor1no • Edited

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.

tailwindcss.com/docs/optimizing-fo...

Thread Thread
 
ravavyr profile image
Ravavyr

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]

Thread Thread
 
ravavyr profile image
Ravavyr

I figured chatGPT would be friendlier about this:

gyazo.com/0ceed27d2e445be4ef2934fb...

Thread Thread
 
danwalsh profile image
Dan Walsh

ChatGPT’s facts don’t care about your feelings 🤪🥲🤖

Glad to see AI agrees with me 😅