Paweł Ludwiczak

Posted on Mar 10, 2021 • Updated on Mar 25, 2022

TailwindCSS @apply - the right approach?

#discuss

I've been experimenting with Tailwind quite a lot recently and there's one thing that I can't figure out... Which of these is better:

.element {
  @apply bg-red ... hover:bg-green ... focus:bg-yellow ...;
}

or...

.element {
  @apply bg-red ...;

  &:hover {
     @apply bg-green ...;
  }

  &:focus {
    @apply bg-yellow ...;
  }
}

The latter example is probably more readable but on the other hand it doesn't utilize Tailwind's variants. So I'm wondering if there's any difference between one and the other? Maybe performance?

Top comments (12)

Ted Goas • Mar 10 '21

I don't know that there's a huge difference for most sites. If you're using tailwind classes in markup, you have to include everything on one line and use the hover:* and focus:* classes.

But if you're using Tailwind classes in CSS files, I think either way makes sense. You could even combine selectors using your latter example:

.element {
  &:hover,
  &:focus,
  &:active {
    @apply bg-green;
  }
}

Instead of writing three classes for hover:bg-green, focus:bg-green, and active:bg-green.

Paweł Ludwiczak • Mar 10 '21

Maybe I wasn’t clear enough: I’m looking specifically at bringing Tailwind classes into my components’ CSS files. And my question is whether I should be using Tailwind’s variants (.el { @apply hover:bg-green; }) OR stick with CSS native pseudo classes (.el:hover { @apply bg-green; })?

Ted Goas • Mar 11 '21

Nope you were clear, I'm saying that I don't think it matters which way you do it. The CSS that Tailwind outputs for its variants is pretty much the same as when you would be outputting by using regular classes inside a :hover {} selector.

Tailwind is nice in that it gives you 2 or 3 ways to do things.

Paweł Ludwiczak • Mar 12 '21

Oh sorry then, maybe I misunderstood your comment initially :)

Anyway - I'm just curious which of these "2 or 3 ways" is more efficient and performant (and IF there is any difference).

Lyrod • Mar 10 '21

Hum, am I missing something? CSS does not support nested selector, so you need to do
.class:focus, .class:hover... { @apply... }

Right?

Paweł Ludwiczak • Mar 10 '21

Oh, I forgot to mention I use SCSS as preprocessor - but that shouldn’t change anything👍

Nino Filiu • Mar 11 '21

@aleksandrhovhannisyan makes a very good point about @apply in his article that has been trending in hacker news:

If it’s not already obvious, @apply completely violates Tailwind’s founding and guiding principles. The fact that this jailbreak even exists is troubling. What exactly is the difference between using @apply and just using the CSS rules that correspond to your utility classes? There is no difference—except now, you’ve defeated the point of using a utility CSS framework in the first place, and you’re better off just writing vanilla CSS to begin with.

Paweł Ludwiczak • Mar 11 '21 • Edited

I'm not sure if I agree with this one. I have a codebase that doesn't use any dynamically generated components (like React - where one file can be responsible for one component). It's more static codebase - with files for entire views and/or parts of it. There's definitely not a react-like component for Buttons - you have to create them by hand.

So it makes perfect sense for me to use utility classes to set up layouts, grids, etc but I'd had to repaste 20 exactly the same utility classes for every of my button

<button class="bg-red text-white px-4 py-2 ...">...</button>

Instead it makes sense to create old-school cool button.css file with something like

.btn {
  @apply bg-red text-white px-4 py-2 ...;
}

And while using utility classes elsewhere in the views (for defining some generic layouts and grid), I still need to create more old-school CSS-only components. You can say that I could do something like this:

.btn {
  background: var(--red);
  color: var(--white);
  padding: var(--s2) var(--s4);
  ...
}

...so I don't have to use @apply but then the question is how to keep my CSS vars in sync with Tailwind (which I'm not sure supports vars that well - I could be wrong here though).

That being said, I think it makes perfect sense to use utility classes in HTML in some places with combination of @apply approach for creating pseudo-components.

mallory-erik • Apr 12 '22

Really late answer, but Tailwind in general lets me develop with speed. I can experiment and create designs uniquely fitting my domain. @apply allows me to clean up and standardize the mess I've made as needed, like a halfway point before converting everything to pure CSS. Maybe you can think of Tailwind as development speed and flexibility on credit, so there's a minor technical debt you accrue. You can "refinance" that debt with @apply. Finally some day, if need be, you can pay it off entirely by switching the whole thing to "proper" CSS.

Simon • Mar 17 '21 • Edited

Hello, I was facing the same this week, I ended to organise my tailwindCSS like this :

.element {
  @apply bg-red ...;
  // Hover
  @apply hover:bg-green ...;
  // Focus
  @apply focus:bg-yellow ...;
  // Active
  @apply active:bg-blue ...;
}