Engineering2 min read364 words

Why I stopped using Tailwind plugins (and what I do instead)

After three years of leaning on every popular Tailwind plugin, I've cut almost all of them. Here is the case for staying close to the core utilities — and the two plugins still worth keeping.

For three years my Tailwind setup looked the same on every project: typography plugin, forms plugin, aspect-ratio plugin, container-queries plugin, animate plugin, sometimes daisyUI. Defaults. Habit.

This year I cut all of them and the result has been faster builds, cleaner DOM, and fewer "why does this style apply" rabbit holes. Here's why.

The hidden cost of plugins

Each plugin adds:

  • More generated CSS, even with JIT — every utility variant the plugin defines is now in your config surface.
  • Cognitive load: a new vocabulary of class names someone on the team has to learn.
  • Coupling: when the plugin's defaults disagree with your design system, you fight it.
  • Upgrade pain: Tailwind v4 broke or changed several popular plugin APIs.

The base Tailwind utility set covers ~90% of what most projects need. Plugins are a tax I'd been paying to skip the 10% I could have just written.

What I dropped and what replaced it

  • `@tailwindcss/typography` → 30 lines of prose styles in my styles.css tuned to my actual brand. Smaller, more predictable, easier to debug.
  • `@tailwindcss/forms` → an explicit <input className="..."> pattern with my own utility set. More verbose, more control.
  • `@tailwindcss/aspect-ratio` → native CSS aspect-ratio property (Baseline 2022).
  • `@tailwindcss/container-queries`@container in raw CSS where I need it.
  • `tailwindcss-animate` → 6 keyframes I actually use, written once in styles.css.

What I kept

  • shadcn-style component snippets: not a plugin, more a copy-paste pattern. Code stays in my repo, I can read it, I can edit it.
  • One project-specific plugin for the brand's spacing scale. Worth it because the scale is genuinely non-default and I'd otherwise repeat 20 @theme lines.

That's it. Two things. Down from seven.

The principle

Every dependency is a bet that the maintainer's defaults will keep matching yours. Plugins compound that bet across many tiny decisions.

If you can write the CSS in 30 minutes once and never touch it again, it doesn't need to be a plugin. Save the plugin slots for things that genuinely require ongoing maintenance you don't want to do — and there are fewer of those than the marketing suggests.

Frequently asked

Common questions

Are Tailwind plugins bad?
No, they're tools. The problem is that most projects add 5+ plugins to solve problems they don't have, then carry that complexity for years. Use plugins when they solve a specific recurring pain, not because the README looks nice.
Work with me

Need this built rather than read about?

I'm a solo developer who scopes, designs, builds and deploys the whole thing. Send a few sentences about your project and you'll get an honest read on scope, timeline and price — usually the same working day.

Written by
Oxymore

Oxymore is a one-person studio shipping MVPs, landing pages, React apps and Telegram bots for founders who would rather move than meet.

Last updated