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.