About 3 years ago I came across Tailwind CSS, an awesome library for website development. To keep this article reasonable short, I won't waste words on introducing it. There are plenty of sources to learn from already. Instead, I want to share a story about a mistake I kept making in my early days with Tailwind. There is no need to fall into same pit as I do.
Tailwind shatters the traditional concept of cascade style sheets by wrapping CSS rules into so called utility classes. Instead of composing CSS rules in .css files, you compose class names directly on DOM elements. While this approach feels unnatural and weird at first, it starts making sense quickly. It took me about a day to get into it and now I don't want to write plain CSS again, unless I am forced to. Tailwind is seamlessly integrated into my #1 framework Nuxt and the simplicity of creating visually appealing responsive-friendly websites within a few minutes is just awesome.
There is a catch, however. The more options you know and the more styles you choose to include, the HTML can bloat into a chaos. The second problem I felt in my early days was repeating myself. As a honorable DRY principle follower, it hurt my eyes to see the very same sequence of classes multiple times in my templates.
I was trying to optimize this.
The first idea was to extract Tailwind classes sequence as a string variable. In Vue.js (Nuxt is built atop Vue), it looks roughly like this.
<-- component before -->
<template>
<div>
<button class="m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold">
Button 1
</button>
<button class="m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold">
Button 2
</button>
<button class="m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold">
Button 3
</button>
</div>
</template>
<-- component after -->
<template>
<div>
<button :class="tailwindBtn">
Button 1
</button>
<button :class="tailwindBtn">
Button 2
</button>
<button :class="tailwindBtn">
Button 3
</button>
</div>
</template>
<script setup lang="ts">
const tailwindBtn = "m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold"
</script>
At last, it is easier to maintain and change. The clarity is arguable. Especially if you have the same elements all around your app and you need to hoist the definition into some global-like constant.
I was looking further for a better solution.
And I was introduced to Tailwind's @apply directive. Basically, it is like a negation of the whole concept. Instead of placing definitions directly on concrete elements, you can create your own sort-of-a-stylesheet and fill it with custom classes and element adjustments. Only instead of plain CSS rules, you brew solutions from Tailwind utility classes.
Weird, but it seemed it will fix my mental problem with duplicate definitions.
I was warned both by the VueSchool tutor and the Tailwind docs NOT to use it, but naturally I didn't listen.
I created a couple of websites using this approach. It worked. Problem solved, or?
Fast forward to late 2024. I got some new ideas for one of my websites. I started coding. I completely forgot about @apply shenanigans I did more than a year ago. And suddenly, I found myself unable to put my layout together.
Although no apparent style was used in my template, my <div>s were off place. What is going on? I opened the dev console in browser to study the rendered HTML. There were CSS styles applied on them.
A few frustrating moments later I got the culprit.
Suddenly, having:
div {
@apply m-auto text-center text-white;
}
in tailwind.css file didn't seem such a great idea as back in 2023.
Who should know I will need something else one day, eh?
LESSON #1
Never, never and ever use @apply globally on an element selector.
While it might look convenient when you scaffold a new project, it can bite you back in the long run. Not only you can easily forgot about it pretty much as I did. It also makes things less flexible. One day you'll come back wiser and ready to get rid of it - but once you remove the global style, half of the site founded on it will unexpectedly break apart. Are you mentally ready to re-think the whole design?
Personally, I would now recommend not to use @apply in tailwind.css at all (if only I have time and patience to rip it off from all my projects where I managed to put it).
If you still insist on using it without a good reason ("like to override the styles in a third-party library" as Tailwinds docs say), at least use it to create classes.
Having some .my-cool-css-class is excusable, because at least you have to attach it to the element you want to style. Like so, everyone (including your future self) can see it there and will be able to find its definition if needed.
YES, BUT
Tempting candidates for breaking this rule are anchor elements. Because it would be really tedious having to attach a class attribute to each <a>.
One possible alternative is to create a custom link component wrapping around the anchor (or around built-in <NuxtLink> in Nuxt). But you might not like it and I won't blame you.
In fact, using @apply directive is still a top ranked solution.
Maybe you can fabricate even more examples where global element styles would make sense. If you are 100% sure, use them. But it should always be a well-founded decision.
LESSON #2
The real reason why you have too-long / duplicate Tailwind class definitions is poor design of your code.
With modern JavaScript frameworks like Vue you were armed with the ability to create small reusable components and put them together to build complex solutions. Use it.
The button example from above can be turned into this:
<-- MyButton.vue -->
<template>
<button class="m-2 p-2 rounded border border-2 border-yellow-500 bg-blue-500 text-black text-lg font-bold">
{{ caption }}
</button>
</template>
<script setup lang="ts">
defineProps({ caption: String })
</script>
<-- app.vue -->
<template>
<div>
<MyButton caption="Button 1" />
<MyButton caption="Button 2" />
<MyButton caption="Button 3" />
</div>
</template>
And just like that, the duplicated code is gone.
Seeing really long class chains on the other hand always makes me think that the poor element was burdened with too many concerns. The best thing to do is to stand back and revise the decisions that lead you there.
My experience is that you can create good-looking designs with only a handful of Tailwind classes. And if you feel like adding more, they usually shouldn't end up piled all on just one element. It is pretty much the same as creating one large component (or a class if you like) doing everything. At some point you really need to stop adding more lines and start breaking things apart.
In the worst case scenario, you should be able to encapsulate visually-demanding CSS elements into separate components and thus minimize the amount of interactions needed. But to be honest, someone probably did that already and all you need to do is to find the right Tailwind component library to use in your project.
Top comments (0)