Tailwind Isn't for Me

Original Article ↗ Hacker News Discussion ↗

Critiques of Tailwind CSS center on its verbose utility classes, HTML “pollution,” and lock-in around non-standard @apply syntax, with some developers arguing that it undermines semantic HTML, accessibility, and long‑term maintainability. Supporters counter that Tailwind improves productivity, keeps styling colocated with components, and reduces common CSS pitfalls like naming, specificity conflicts, and unmanaged stylesheet bloat—especially in large or rapidly developed apps. The exchange highlights a broader tension between “boring” vanilla HTML/CSS and newer abstractions, as well as differing priorities around speed of development, readability, and future-proofing.

Overall sentiment

  • Thread is sharply divided: some see Tailwind as a huge productivity win, others view it as ugly, proprietary, and bad for long‑term maintenance.
  • Many argue the choice is largely about personal workflow, project scale, and tolerance for tooling lock‑in.

Productivity vs. maintainability

  • Fans say Tailwind:
    • Eliminates naming CSS classes and managing large stylesheets.
    • Keeps “locality of behavior” — styles are next to the markup/component, easier to copy‑paste and reason about.
    • Speeds up prototyping and MVPs, especially for non‑CSS experts.
  • Critics say:
    • Long class attributes become unreadable, especially with 20–50 utilities on one element.
    • Refactoring months later, or by someone else, is painful.
    • It encourages “div/span soup” and weak semantics, hurting accessibility and performance.

CSS, architecture, and separation of concerns

  • One camp emphasizes separation: HTML for structure, CSS for styling, JS for behavior. Tailwind is seen as a regression toward inline styles and “spaghetti”.
  • Others argue strict separation is overrated; collocating styles with components reduces context‑switching and CSS‑specific pitfalls (specificity wars, !important abuse).
  • There’s debate over whether Tailwind is “just inline CSS” (critics) vs. a constrained, theme‑driven utility system that avoids many inline‑style problems (supporters).

Lock‑in, tooling, and portability

  • Some worry Tailwind’s @apply and JS‑defined design tokens are proprietary and make styles non‑portable.
  • Others point to tools that convert between Tailwind and plain CSS, and projects aimed at “de‑Tailwinding” code.
  • Concern: needing a build step and JS tooling even for CSS; others note many stacks already have a build pipeline.

Web components, custom elements, and Shadow DOM

  • Debate over using custom elements (e.g., <ui-card>) to avoid div soup:
    • Some argue you can use undeclared tags purely for semantics and CSS targeting.
    • Others stress this is not the same as true custom elements, which require JS and Shadow DOM.
  • Shadow DOM is criticized as a problematic abstraction that complicates styling and integration with Tailwind and other tools.

Alternatives and middle-ground approaches

  • Mentioned alternatives: PicoCSS, vanilla CSS with modern features, CSS Modules, Styled Components, LESS/SASS, atomic/utility libraries, and tools that extract Tailwind into regular CSS.
  • A common compromise: use utilities for layout/structure, custom classes or components for look & feel; bundle Tailwind classes inside component abstractions.

Meta-discussion: tech fashion and “boring tech”

  • Several comments lament constant framework churn and technology as fashion.
  • Some advocate “boring” HTML/CSS/JS without heavy tooling; others defend experimentation and note that frameworks often influence future standards.