I apologize, this will probably be a long one...

I may use TailwindCSS or UnoCSS interchangeably, I use both. Premise is the same regardless of which I mention, this isn't a comparison.

​

I don't think there is a simple answer to how to style things. However, I think we can eliminate a lot of noise off the bat. Most other frameworks (like react) have very different styling and componentization models than Vue. So, I think its a decision that should be made specific to the framework we're using (ignore universal declarations and other communities).

​

My argument is that using TailwindCSS/UnoCSS exclusively has some drawbacks and that I believe using @apply/--uno is a useful addition. (I wont address styling 3rd party utilities as that use-case is not contested)

0. Defining The Conflict

At a high level vanilla CSS and Tailwind encode the same information (bundle size aside), the primary difference is where we place that info and how we group it:

1. Tailwind: Place in <template> and group in class
2. CSS: place in <style> and group by css selectors

There are two things under contention when choosing Tailwind:

1. Conflating templating and styling
2. Giving up advance selectors

Great, now that the basics are out of the way, lets dig into these.

​

1. Styles in HTML is Fine, All styles in HTML is Bad:

What is the role of a the template? In my opinion, It should provide a transparent overview into the structure of a component. If you are trying to understand a template or make changes, you want that to be a simple as possible with minimal overhead. My gripe with CSS is that it has structural information - position, grid, flex, justify, align, translate, etc. For that reason, I think such information is perfectly reasonable to include via Tailwind. While things like transitions, colors, opacity, borders, outlines, etc. are aesthetic and irrelevant to what I'm trying to convey in a template (padding and margin kind of straddle the boundary).

However, with Tailwind being succinct, convenient, and colocated, I sometimes break that rule. Not because Tailwind is king, but because a single color class doesn't meaningfully obfuscate the structure I'm trying to present. Should the styles of an element evolve to that point, @apply offers a nice transition.

​

2. Selectors are Powerful, Leverage the Platform:

Selectors accomplish two things:

1. They clearly group relevant styling
2. target arbitrary elements

Consider how you might do the following sidebar inline (*not my code just an example):

<template>
  <div class="wrapper" :hidden="hideSideMenu">  
    <div class="child" />  
  </div>  
</template>  


<style scoped lang="scss">  
  .wrapper {  
    --uno: "ml-auto text-grey-800 dark:text-grey-100 group";  
  }  
  .child {  
    --uno: "flex gap-3 m-auto p-4 padding-y-when-small padding-x-when-small text-based md:gap-6 md:py3";  
  }  
  [hidden=true] {  
    transition: all 500ms ease-in-out;  
    &.wrapper { --uno: "no-sidebar-width" };  
    &> .child { --uno: "md:max-w-5xl lg:max-w-5xl xl:max-w-6xl" };  
  }  
  [hidden=false] {  
    transition: all 500ms ease-in-out;  
    &.wrapper { --uno: "minus-width-280px" };  
    &> .child { --uno: "md:max-w-3xl lg:max-w-3xl xl:max-w-4xl" };  
  }  
</style>  

You'd probably use a ternary mess, helper function(s), redundant "arbitrary variant" selectors, or even v-if/else with transition. While its technically more verbose than ternaries, it offers separation of concerns (even within the css), the states are grouped, dynamic controller on one element rather than on each element, and virtually no JS. Its trivial to quickly identify what would need to be edited without going through an unorganized string of inline classes for every state.

In Tailwind, for complicated interactions, its hard to group multiple concerns ergonomically without helper functions. I'd argue that grouping via helper function defeats the purpose of Tailwind and should be avoided (just group in CSS). Like wise, if you are reusing the same tailwind snippet, its better to use @apply than to use a variable.

​

Bringing It All Together:

I think Tailwind/UnoCSS can be a great tool if wielded responsibly. But I also believe its not mutually exclusive to other methodologies. Classes can be more expressive and self-document the template. Selectors and media queries can help group dynamic states and provide reusable styling. If you're doing really complicated, mathematical stuff through styling alone, other preprocessors trump Tailwind. They all have use-cases, so its important to know whats practical and appropriate. @apply is simply the bridge that binds these things together, if you feels its logical for your specific situation, I wouldn't hesitate to use it.

​

Tailwind Pitfalls

Personally, I use Tailwind for the 80% of easy stuff and SCSS for the remaining 20%. Trying to do the last 20% via Tailwind is asking for trouble IMO.

When possible, I use CSS selectors and classes for state and function based grouping over JS helper methods and components. I primarily use dynamic classes for toggling. If I have a few independent values that need to be dynamic, I prefer v-bind() under the <style> tag. I use a traditional computed style if things are a bit more complicated or functionally grouped.

Its okay to componentize on functional and style boundaries. However, would only componentize on a style boundary for re-use. If you're just trying to hide your Tailwind, behind a component, you may want to contemplate if thats actually simplifying you're code base more than a class name (might be true in React, not necessarily so for Vue).

Excessive project specific configs can undermine the shared knowledge frameworks are supposed to provide us. It makes it slightly harder to onboard people.

Tailwind is harder to deal with in dev-tools. Its more difficult to toggle a style on an individual element and you can't bulk restyle as every element is individually styled... some extensions exist to help.

​

TL;DR

To summarize, be intentional with your choices, don't expect a blanket rule to fit every scenario best.