Web components are okay

Original Article ↗ Hacker News Discussion ↗

Role and Intended Use

  • Many see Web Components (WCs) primarily as a distribution mechanism: build a UI element once and use it across any framework (or none), including third‑party sites and micro‑frontends.
  • They are not viewed as a full application framework: they don’t solve state management, routing, or app‑level data flow by themselves.
  • Best framed as browser‑native, framework‑agnostic custom elements that encapsulate structure, styling, and behavior.

Adoption and Ecosystem Dynamics

  • Despite being in browsers, WCs are seen as under‑marketed and overshadowed by React/Vue ecosystems and employment incentives.
  • New devs often follow social proof and jobs, not platform primitives; framework authors are frequently skeptical and see WCs as a failed or blocking experiment.

Performance and “Interop Tax”

  • Critics worry about an “interop tax”: each WC library shipping its own runtime, compounding JS size and long‑term bloat.
  • Supporters counter that many runtimes are small, most apps already ship far more JS (especially React), and typical WC use (few heavy components) keeps overhead acceptable.

Shadow DOM, Styling, and Isolation

  • Strong split:
    • Pro: Shadow DOM gives CSS isolation, protects against host styles and name collisions, good for embeddable widgets and multi‑team systems.
    • Contra: Makes theming and global styling harder, interacts badly with Tailwind/Bootstrap, testing, scraping, browser extensions, and user CSS.
  • Many WC users avoid Shadow DOM for app UIs, using light DOM only; some call Shadow DOM the most oversold part of WCs.

Developer Experience and Tooling

  • Raw WC APIs are described as low‑level, verbose, and “wart‑y”; common advice is to use a helper framework like Lit or Stencil.
  • Complaints include: awkward lifecycle, slots requiring Shadow DOM, form integration issues, inability to unload/reload different versions, and weak server‑side rendering/hydration story.
  • Others report good experiences building apps with “light DOM WCs + small templating (e.g., lit‑html)”, valuing reduced dependencies and long‑term stability.

Good Fit Use Cases

  • Embeddable widgets (chat, maps, tables, emoji pickers), cross‑framework design systems, partner/affiliate embeds, and progressive enhancement on otherwise server‑rendered pages.
  • Particularly attractive where teams can’t afford ongoing framework churn or dependency hell.

Critiques and Limitations

  • Some argue WCs replace one set of problems (framework lock‑in) with another (platform complexity, awkward APIs).
  • Safari still lacks full WC support (no customized built‑in elements).
  • A vocal minority is strongly negative, calling WCs overengineered, poorly designed for real apps, and inferior to modern frameworks’ component models.

Meta: Frontend Culture

  • Thread repeatedly notes “tech tribalism”: frameworks, WCs, and related tools are treated like religions, making balanced discussion difficult.