I don't recommend Tailwind CSS

Original Article ↗ Hacker News Discussion ↗

Tailwind CSS polarizes frontend developers: some see its utility-first classes as an elegant way to tame large, messy stylesheets and make components self-contained and easy to reuse across big teams. Critics argue it bloats markup, obscures semantics, weakens the separation of structure and design, and ultimately just re-abstracts CSS while still requiring you to understand the underlying language. Many conclude that the “right” choice depends heavily on context — project size, team skills, and tooling — with alternatives like modern vanilla CSS, CSS Modules, BEM, or UI libraries often preferred for long-term maintainability.

Overall Tone

  • Discussion is highly polarized and repetitive of past Tailwind debates; many call it bikeshedding.
  • Several note Tailwind’s continued popularity as evidence it solves real problems; others see its spread as a sign of weak frontend leadership or “slop.”

Perceived Benefits of Tailwind

  • Speeds up implementation, especially for devs who don’t want to design a CSS architecture or naming scheme.
  • Utility classes make components/pages self‑contained; changes are less likely to cause cascade regressions elsewhere.
  • Consistent design system can be centralized in Tailwind config (colors, spacing, radii, dark mode, etc.), then reused via utilities.
  • Works well in large teams and codebases by avoiding divergent BEM conventions and CSS “spaghetti.”
  • Easy to copy/paste elements between projects and have them look identical.
  • Autocomplete, IDE tooling, and AI assistance make the class names easy to remember and apply.

Main Criticisms

  • Markup becomes noisy and hard to read; class attributes encode a mini language instead of using semantic classes.
  • Breaks or blurs “structure vs style” separation; feels like going back to inline styles.
  • Requires learning Tailwind’s vocabulary in addition to CSS; experienced CSS devs report it slows them down.
  • Cascade/priority issues (e.g., conflicting utilities) undermine “local reasoning,” leading to add‑ons like tailwind‑merge.
  • Use of @apply is contentious: some see it as necessary for sanity, others say it defeats Tailwind’s purpose.
  • Encourages ad‑hoc one‑off values (p-[13px], mixed color scales), so consistency still depends on developer discipline.

CSS, Components, and Alternatives

  • Several argue CSS itself (and HTML’s model) is the root problem; Tailwind is one pragmatic coping mechanism among many.
  • Others prefer modern CSS with variables, nesting, scoped styles, CSS Modules, or BEM, often combined with component frameworks.
  • Some split responsibilities: CSS or design systems for tokens and semantics; Tailwind‑style utilities only for layout/typography.
  • A few note that with LLMs/agents generating CSS, Tailwind’s main advantage (fast hand authoring) may matter less over time.

Context and “Right Tool” View

  • Many conclude suitability is context‑dependent: good for large teams, prototypes, and utility‑heavy UIs; less compelling for small, well‑designed, component‑scoped CSS codebases.