Is @apply still considered a best practice in Tailwind CSS v4?

[zaman1100]

With Tailwind CSS v4 emphasizing utility-first workflows and CSS-first configuration, I'm wondering what the current recommendation is for using @apply.

Is it still considered a good practice for reusable component styles, or is it now discouraged in favor of composing utilities directly in the markup? I'd be interested to hear the team's recommendation and how others are using it in real projects.

[RobinMalfait]

It was never considered a best practice, but you can definitely still use it. This is what we recommend: https://tailwindcss.com/docs/styling-with-utility-classes#managing-duplication

[DucMinhNe]

Short Answer

In Tailwind CSS v4, @apply is still supported, but the core recommendation remains the same: composing utilities directly in your markup (or within component abstractions like React/Vue/Svelte components) is the preferred best practice.

@apply is primarily intended as an escape hatch for cases where you cannot modify the HTML markup directly.

---

Official Guidance & Best Practices in v4

1. When to avoid @apply (General UI Components)

• Duplicated CSS Output: Using @apply inside many custom CSS classes forces Tailwind to generate duplicated CSS rules for each custom class. This defeats the primary performance benefit of atomic CSS (where utility classes are generated once and reused everywhere).
• Naming Overhead: It re-introduces the burden of inventing BEM-style class names (.btn-primary-lg-active) for every UI element.
• Loss of IntelliSense & Variant Utility: Modifiers like hover:, focus:, dark:, and responsive breakpoints (md:, lg:) are much cleaner and more maintainable when expressed directly in utility strings or component props.

2. When @apply is appropriate

@apply is still useful for specific scenarios where utility classes cannot be attached directly to HTML nodes:

• Markdown Content: Styling raw HTML rendered from markdown (.prose p { @apply text-base leading-relaxed; }).
• Third-Party Libraries: Overriding styles for third-party DOM widgets (datepicker, rich text editor, embedded maps).
• Custom Elements / Shadow DOM: Elements inside closed Shadow Roots where global utility classes cannot penetrate.

---

Modern Alternatives in Tailwind v4

1. First-Class Custom Utilities (@utility):
   Tailwind CSS v4 introduces the @utility directive in CSS for defining true custom utilities that integrate directly with v4 engine:

   @utility tab-highlight {
     outline: 2px solid var(--color-blue-500);
     outline-offset: 2px;
   }

2. Component Abstractions + cva / clsx:
   For UI components with multiple variants (buttons, badges, inputs), combine framework components with class-variance-authority (cva) or tailwind-merge instead of writing large @apply blocks in CSS:

   const buttonVariants = cva("inline-flex items-center justify-center rounded-md font-medium", {
     variants: {
       variant: {
         primary: "bg-blue-600 text-white hover:bg-blue-700",
         secondary: "bg-gray-200 text-gray-900 hover:bg-gray-300",
       },
     },
   });

Summary

Keep using utility classes in your component markup. Use @apply sparingly as a targeted escape hatch when you do not control the HTML structure.