My journey and experienced trade-off with Tailwind CSS

In this article I will summarize my experience with Tailwind CSS. Why I have chosen it and why I have ejected it again after a while.

Motivation

I was in the lucky position to start a new web project. For styling I want to utilize utility classes.

My expectations for utility classes were:

• Naming things is hard. It takes time and effort. Bad chosen names make maintenance harder. Don't have to think about names like some-wrapper-for-whatever-reason and have to maintain them, should save time and energy to be more productive.
• Switching contexts and mapping between them is exhausting. Switching from and mapping between an HTML and a CSS file seems like a small thing. But I believe that the amount of contexts a programmer has to manage in his head is a bottleneck for good coding. Every little bit helps.

My expectations for Tailwind CSS were:

• It should help to get started quickly, as I don't have to create all utility classes by myself.
• It should ensure a standardized naming scheme for utility classes, as it is a well battle-tested library.
• It should protected me against zombies of once created but after a while unused utility classes, littering my CSS.

Experienced pros

So let me wrap up my experienced pros:

• Utility classes let me code quickly new components and glue them together.
• IDE support in VS Code is great. Tailwind CSS IntelliSense supports autocomplete, linting and inline translation of applied CSS rule.
• It offers more than plain utility classes. For example, instead of box-shadow: 0 1px 3px 0 rgb(0 0 0 / 0.1), 0 1px 2px -1px rgb(0 0 0 / 0.1) you can apply class name shadow or for box-shadow: 0 4px 6px -1px rgb(0 0 0 / 0.1), 0 2px 4px -2px rgb(0 0 0 / 0.1); you can apply class name shadow-md. This is nice for two reasons. First, shadow and shadow-md are good short names. Second, the resulting shadow looks nice and saved me a few minutes of experimenting for myself with shadow values.
• The integration of Tailwind CSS into the build system ensures, that only class names, that are actual used, are included in the production build. A view observed falsely integrated class names are negligible.

Experienced contras

Unfortunately, as far as I know, there is no golden bullet to catch them all in Software Architecture no matter the topic, but everything is a trade-off. Here are the contras I experienced with Tailwind CSS:

• Let me start with an example: <section class="grid w-full grid-cols-[1fr,min(var(--width),100%),1fr] place-items-center gap-y-4 [&>*]:col-start-2">...
  • This is quite long. I have to read my code many times (and yes, HTML is code as your JavaScript is or as your CSS is). Every time I am looking for something in my HTML, I get distracted a little by this amount of code.
  • How should I format this code? In general I think a line length of 80 character is good for readability. We have already crossed that limit without even adding colors, colors for dark mode, ... So how do we split it up? How is it compatible with my existing formatting tooling like Prettier? So formatting is something I have to spent more time and energy on.
  • One alternative for too many utility classes is to use them only, when you need a few. Use traditional classes otherwise or even combine them. For now, I think this is a good idea. But to be honest, it's a trade-off. You have to wonder how many are too much and you have to search for styles in two places.
  • grid-cols-[1fr... or [&>*] are extra syntax I have to learn and remember, when writing and later reading this code.
  • When some styles don't work as expected, the output in the DevTools is bloated. The rule [&>*]:col-start-2" gets compiled to .\[\&\>\*\]\:col-start-2>* { grid-column-start: 2; }. In addition, there are a lot of small rules in the styles section and a ton of never used CSS variables.
• Tailwind CSS adds build complexity (as a side note, I now think Tailwind CSS is a framework and not a library, as it forces you to integrate a specific build configuration):
  • It needs a configuration file, which feeds a PostCSS plugin under the hood.
  • It increased my build time by almost 10 seconds.
  • I have a shared Angular component library and a consuming app. Enabling sharing of generated class names needed extra thought. Hot reload of Tailwind CSS class names doesn't always work, decreasing my development feedback cycle. I am not sure, if this is a misconfiguration on my side, or a problem with Angular's and Tailwind CSS's compatibility. No matter what, debugging a "it works sometimes" problem always sucks and I haven't figured out that one so far.
  • Native CSS Nesting requires an extra Tailwind plugin - what makes it not very native to me.
• I am not perfectly happy with all Tailwind CSS naming schemes. For example, I think content-center should be named align-center to align with the other flex direction, which is named justify-center in Tailwind CSS. Or I think text-base should be named text-4 to align with p-4.

Sum up

I think utility classes speed up your development and can help you with maintenance, if you don't overuse them. My opinion to Tailwind CSS is, that it adds more contras than pros and therefore, I am going to eject it from my project.

Final kudos to Tailwind CSS

I am grateful for Tailwind CSS. It helped me to get quickly started with utility classes. There is a lot of good documentation and reasoning about utility classes in Tailwind CSS's documentation and related resources.

And the best part is, I always knew that I can eject it easily. I can just generate all current class names via npx tailwindcss -o utility.classes.css, include the plain CSS file in my project and refactor class names however I want later.

Comments

[Ihsen Bouallegue]

Hey!

Lovely blog. It is clear that you thought about this long and hard and tried to view tailwind from both sides, the good and the bad. However, I want to slightly challenge your arguments. I am mainly a React dev and tailwind has been one of the best jumps I ever did.

• Long Class Names: the problem with long class names. Yes, I agree it can get distracting at some point, especially when there is no composition, and you have one huge component that has a lot of styling. For me, it's a sign that I need to reconsider how I structured things. But if it's really annoying for you, there is an awesome extension called tailwind fold (if you are using VS Code) that hides class names until you purposefully hover or click them.

• The Learning Curve: yes, there is a learning curve to it. But it is one well worth the time investment. It is one of those things that's awkward at first but pays off immensely in the long run. Now that my brain memorized all the common class names. I can prototype crazy fast. And I mean CRAZY fast. Building fully styled components in minutes. While with normal CSS it takes 10 review rounds to just find the best name for a class, a user will never care about. I honestly didn't have problems with the debugging the CSS. I just use the browsers' dev tools, and they work perfectly fine.

• Build Process: Additional 10 seconds seem like a very long time for tailwind. While I never had that drastic increase in a React project, It might be an Angular thing, along with the hot reload problem. Concerning the build time. It has been fixed and being releases in the next version (awesome release btw with some really well thought changes). It should reduce the build time to about a second for your case. Which is fully acceptable for the benefits it brings. Concerning the hot reload, I didn't have that problem myself, but I know angular is not so friendly in that regard. Still, I think it must have been already solved, but you have to invest a bit of time in debugging.

• Some Class Names are Weird: here I fully agree, those class names in particular I don't like and hope they would change soon or at least introduce aliases for. But the good thing, those are the only ones I don't like, so I can tolerate it as it's not a big deal.

Finally, I find your points totally valid. I went through that struggle at first. But in my experience, you should fully commit to utility classes and stop using normal CSS to see the full benefit.

Plus, personally, I don't see tailwind as a replacement for CSS. It is much, much more. For example, It takes care of theming, one of the hardest and most annoying things to do right. Lately I am also doing a lot of animations. The shortcuts' tailwind gives me are outright insane. What in CSS would be 100 lines, in tailwind is a couple of cleverly placed utility classes (that my brain can easily remember and later reuse). Also, tailwind-typography is a gem. It makes me produce some very good-looking results (what's most important for the user) with so little code. And the list of benefits goes on and on...

I hope, with this in mind, you give it another try in a smaller project. Once you are over the learning curve, you will see a crazy productivity increase that's well worth it. Thank you for sharing!

[shaman-apprentice]

Thanks for your insights! I see nothing to disagree with - just choosing different sides of the trade-off. I wouldn't mind working with Tailwind CSS in a project if there is already a senior team working with it.

Just a site note:

For me, it's a sign that I need to reconsider how I structured things.

I totally agree with that :) But sometimes it is nice and I think also valuable to go quick and dirty and have as few hurdles as possible along the way (which is again a trade-off ;P )