Facebook just updated its relationship status with Web Components

Original Article ↗ Hacker News Discussion ↗

Overall theme

  • Thread debates the practical value of Web Components (WCs), especially in light of React adding better WC support.
  • Strong split between people excited about standards-based, framework-agnostic UI, and those frustrated by WC ergonomics and ecosystem gaps.

Corporate experience and maintainability

  • Some report internal WC libraries as painful: hard to “hotfix” behavior/styles because internals are hidden behind Shadow DOM and fixed event APIs.
  • Others argue this is a bureaucracy/process issue, not a WC problem; the same orgs ship fragile React or jQuery libraries.
  • Pro‑WC view: shadow encapsulation reduces brittle dependencies on internal DOM/CSS, making upgrades safer.

Encapsulation vs styling and Shadow DOM

  • Major recurring tension: component encapsulation vs app‑level styling/theming.
  • Complaints:
    • Hard to override styles unless parts, slots, or CSS custom properties are explicitly exposed.
    • Styling nested components becomes recursive and complex.
  • Defenses:
    • Good WC authors expose parts, slots, and CSS vars; examples of design systems that handle this well.
    • CSS variables and slots can propagate theming down component trees, but require discipline and documentation.
  • Some prefer avoiding Shadow DOM entirely to keep styling simple.

Use cases: libraries vs app internals

  • Broad agreement: WCs are strongest for:
    • Cross‑framework component SDKs (e.g., a video player shipped once, wrapped for React/Vue/etc.).
    • Long‑lived, migration‑resistant UI pieces.
  • Many argue there’s little inherent benefit for app internals compared to React/Svelte/Vue, which provide state, templating, and tooling.

React, state, and ergonomics

  • React praised for declarative state→UI; going “vanilla + WCs” often feels like tedious manual state and DOM management.
  • Counterpoint: React’s own ecosystem churn (classes→hooks, state libs like Redux) has been painful.
  • Some would still “take WCs over React” due to dislike of React’s complexity, but this is minority and opinionated.

Longevity, standards, and ecosystem

  • Pro‑WC side:
    • WCs are web standards, implemented in browsers, closer to “bare metal,” so more likely to keep working over decades.
    • Easier to port a standalone WC later than a React component tied to a build system and dependency graph.
  • Skeptical side:
    • Web is full of abandoned standards; adoption matters more than specification.
    • React has had unusually long dominance; large trained developer base provides its own form of durability.
    • Old nonstandard but popular formats (e.g., jQuery‑heavy code) are often still easier to revive than obscure standards with little ecosystem.

Missing pieces and standards gaps

  • Critics list many pain points that exist because of WCs/Shadow DOM:
    • Global custom‑element registry and name collisions.
    • Styling/theming across shadow boundaries.
    • A11y/ARIA spanning shadow roots.
    • Forms integration, lazy definition, selections across composed trees, shared stylesheets, theming, etc.
  • A W3C community document enumerating ~20 related proposals is cited as evidence WCs needed lots of extra specs to reach parity with framework features.
  • Defenders say many of these are exactly the kind of cross‑framework problems that should be solved at the platform level.

Browser support and customized built‑ins

  • Frustration that WebKit has refused to ship “customized built‑in elements” (extending <button>, <a>, etc.), blocking some patterns and forcing workarounds.
  • Dispute over whether WebKit has offered adequate technical alternatives vs simply avoiding a large refactor.

Global registry and namespacing

  • Concern: WCs are globally registered; two libraries can’t both define <my-button>.
  • Some argue this is a design flaw that should have been solved with scoped registries from the start.
  • Others say HTML’s flat namespace model is intentional; using prefixes (e.g., lib-button) works in practice, similar to older ecosystems.

CSS sharing and tooling

  • Practical issue: sharing base styles across many WCs without duplication.
  • Suggestions:
    • Shared CSSStyleSheet (constructable stylesheets) added to each shadow root.
    • Framework helpers (e.g., Lit’s style inheritance and shared style modules) to centralize CSS.

Attitudes toward adoption

  • Some devs note they’ve never needed WCs in many years and that’s acceptable; not every project benefits.
  • Others expect WCs to become more “plumbing” under the hood of frameworks rather than a direct replacement for them.
  • Several emphasize that WCs are currently more valuable for library authors and browser vendors than everyday app developers.