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.

[gitsult4n]

@apply is still fully supported in v4 — it hasn't been removed or deprecated. The official stance is unchanged from v3: composing utility classes directly in markup is the primary, recommended workflow. @apply is meant for edge cases — third-party HTML you can't add classes to (CMS content, markdown output), or a genuinely repeated multi-utility pattern you want to extract once. It's not "discouraged," but it's not the default way of working either; the team still pushes utility-first-in-markup as the main pattern.

[shiliaiwei]

In Tailwind CSS v4, using @apply is generally discouraged and not considered a best practice, exactly in line with the official Tailwind team's design direction for v4.

Here is why and what you should use instead:

Why @apply is discouraged in Tailwind v4:

1. Defeats the Utility-First Philosophy: Overusing @apply turns Tailwind back into traditional semantic CSS (BEM), re-introducing the pain of inventing class names and maintaining separate CSS files.
2. Duplicated CSS Output: Every time you write @apply in multiple classes, it duplicates compiled CSS declarations rather than reusing utility classes in the DOM, increasing your final CSS bundle size.
3. Loss of Colocation: When you use @apply, you lose the ability to see how an element is styled directly in your component/JSX markup.

---

What to use instead in Tailwind v4:

1. Use Component Abstractions (Recommended)

Extract reusable UI elements into framework components (e.g., React, Vue, Svelte, Blade, or Astro) instead of CSS classes:

// Reusable Button Component
export function Button({ children, variant = 'primary' }) {
  return (
    <button className="px-4 py-2 rounded-lg font-medium bg-blue-600 hover:bg-blue-700 text-white transition-colors">
      {children}
    </button>
  );
}

[paramjeetn]

In Tailwind CSS v4, @apply is still supported, but the recommendation remains the same as v3: favor composing utilities directly in your markup or UI component templates (React/Vue/Svelte/Astro components) over extracting premature custom CSS abstractions with @apply.

Key points for Tailwind v4:

1. Utility-First & CSS-First Config: v4 moves configuration into CSS @theme and @utility blocks.
2. If you need custom reusable classes in v4, the recommended mechanism is the new @utility directive instead of raw @apply blocks:

@utility btn-primary {
  background-color: var(--color-blue-600);
  padding: 0.5rem 1rem;
  border-radius: 0.375rem;
  color: white;
}

3. @apply is still useful for third-party library styling overrides (e.g. styling un-modifiable Markdown HTML elements from a headless CMS), but for your own application components, template composition is the cleanest path.

[MalikHettige]

To summarize the official team stance and the core ecosystem direction for Tailwind CSS v4:

1. It's not deprecated, but it was never a "best practice": @apply is still fully supported in v4, but the primary recommendation is still to compose utilities directly in your HTML markup or rely on framework component abstractions (React, Vue, Svelte components).
2. Performance Impact: Overusing @apply to build custom CSS classes duplicates declarations in your compiled stylesheet, which defeats the performance benefit of using an atomic utility-first framework.
3. The New Alternative (@utility): If you absolutely must create a custom reusable class within your CSS file, Tailwind v4 introduces the new @utility directive, which integrates natively with the v4 compiler engine rather than just dumping standard @apply blocks.
4. When to use it: You should treat @apply strictly as a targeted escape hatch for code structures you don't control, such as styling raw HTML output from a Headless CMS or overriding standard classes from third-party libraries.

[Icaro0310]

It's still supported, but no longer the recommended default. The v4 docs still nudge you toward extracting components (React/Vue/etc.) or using @utility for custom utilities instead of @apply classes in CSS.

In practice, in my projects I use it like this:

• Repeated patterns (buttons, inputs, card shells) → a component or a @utility:

@utility btn {
  @apply rounded-lg px-4 py-2 font-medium transition-colors;
}

Then class="btn btn-primary" — this keeps variants and hover: working properly, which raw @apply in a plain class doesn't give you.

• One-off fixes where markup is hard to touch (third-party HTML, prose) → plain @apply is fine.

One v4 gotcha: in a CSS file processed separately, @apply needs @reference "tailwindcss"; at the top or it won't resolve.

So: utilities in markup → @utility for reuse → @apply for edge cases.

—
More of my work lives here: github.com/Icaro0310 · Website: icaro0310.github.io