TailwindCSS is great; why so much hate? (2024)

Dan Walsh

• Feb 2 '23

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!

Dan Walsh

• Feb 2 '23

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

Rense Bakker

• Feb 3 '23

Christian Barrionuevo

• Feb 4 '23

david

• Aug 27 '23

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

Dan Walsh

• Feb 4 '23

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.

Dan Walsh

• Feb 4 '23

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:

Adam Wathan

@adamwathan

I can say with absolute certainty that if I started Tailwind CSS over from scratch, there would be no `@​apply` 😬

The behavior is outrageously complicated, everyone struggles to build the right mental model of what it's supposed to do, and it encourages bad CSS architecture.

18:47 PM - 15 Aug 2022

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:

Adam Wathan

@adamwathan

I estimate that we spend at least $10,000/month trying to debug extremely edge-case issues people run into by using `@​apply` in weird ways 🥴

Not a joke, actual back of the napkin math.

And it's not even a good feature!

19:34 PM - 07 Jan 2022

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

Dan Walsh

• Feb 2 '23

Dan Walsh

• Jun 7

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 ☺️

Dan Walsh

• Jan 3

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;}

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 🕊️