Vanilla JavaScript support for Tailwind Plus

Original Article ↗ Hacker News Discussion ↗

Implementation details & use of web components

  • Tailwind Plus’ vanilla JS support is implemented as standards-based custom elements (@tailwindplus/elements).
  • Components do not use Shadow DOM (confirmed via inspection), which affects styling and event propagation; some consider this an advantage.
  • The elements are “headless”: they handle behavior and accessibility while leaving styling to Tailwind classes.
  • This approach allows usage across environments (Rails, Django templates, Vue, React, plain HTML) via a script tag or npm, avoiding framework-specific wrappers.
  • Some note this effectively restores/extends framework support (e.g., Vue) through web components instead of separate packages; others remain wary due to past abandoned Vue-specific packages.

Licensing, pricing & business model

  • Tailwind CSS itself remains free and open source; Tailwind Plus (UI components, templates, and now elements) is paid with a one-time, perpetual license.
  • Several commenters find it odd or “hilarious” that vanilla JS/headless components are behind a paywall, expecting the opposite (free primitives, paid framework integrations).
  • Others argue it’s reasonable: the library reportedly cost around $250k to develop; paid components are the Tailwind team’s main monetization path.
  • Confusion stems from the blog title and branding; some readers initially thought “vanilla JS support for Tailwind” itself was paywalled.
  • There’s discussion of revenue decline (blamed partly on AI and OSS alternatives) and a new corporate sponsorship program to support more free work.

Tailwind vs Bootstrap, CSS & design systems

  • Many criticize “class soup” (long Tailwind class lists) as unreadable and non-semantic, comparing unfavorably to Bootstrap’s shorter semantic classes.
  • Defenders say utility classes localize behavior, avoid cascade/specificity problems, and provide a shared “standard library” of spacing/colors.
  • Some teams wrap utilities into higher-level classes/components (.card, .btn) or use @apply, effectively layering semantic abstractions on top of Tailwind.
  • There’s substantial debate on whether Tailwind is a healthy evolution of CSS (functional/atomic, design-token-driven) or an overreaction to poorly managed traditional CSS.

Web components: enthusiasm & friction

  • Many welcome a major project embracing web components and see them as ideal for cross-framework UI distribution.
  • Others report disappointments: awkward lifecycle for TypeScript, attribute handling, performance and SSR issues in React, and lingering scars from Polymer-era designs.
  • Some argue web components shine mainly as a universal, framework-agnostic base; anything deeper tends to conflict with framework patterns and data binding.