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.
Peace ποΈ
Latest comments (31)
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.
Fair call! Especially if you don't have the screen realestate to have your code editor and your browser side-by-side to see the code changes hot-reload on save.
There definitely needs to be a balance between all aspects of your project including, but not limited to, scalability, maintainabilty, and developer workflow. You've got to choose the right balance for you.
Appreciate your comments βΊοΈ
Previously I would write a reusable component ActionList and do some instances of it like
With tailwind I have to replicate ActionList and clutter each markup-tag there with different classNames. I don't understand why people use tailwind.
Can you believe this article taught me β + D
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.
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
cardorsubtitleorpromo-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 applydisplay: 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
leadingvsline-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-3to 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: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
@applysyntax 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 ποΈ
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.
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.
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.
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".
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.
Can you please provide some examples? Prettier itself is "JavaScript with JSX" agnostic and supports many languages, IDEs and tools.
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! ππββοΈ
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 π
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.
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.