What We Need Instead of "Web Components"

Original Article ↗ Hacker News Discussion ↗

Critiques of Web Components center on their complexity, weak semantics, and poor fit with how modern JavaScript frameworks actually build UIs, with many arguing that they add brittle specs without solving core problems like state management, reconciliation, and styling. Commenters instead call for browsers to standardize lower-level primitives developers already converge on—such as better DOM diffing, reactivity, and UI widgets—while others defend Web Components (often via libraries like Lit) as a useful, framework-agnostic way to encapsulate interactive elements. The exchange broadens into concerns about JavaScript ecosystem churn, overlapping standards like Observables and signals, and whether the web should move toward more native-like or binary application models.

Standards, browsers, and governance

  • Debate over who Web Components are really for: app developers vs. browser/standards engineers.
  • Disagreement about W3C vs WHATWG roles: some see W3C as formalizing WHATWG’s de‑facto specs; others highlight frictions (HTML snapshots, privacy, spec changes that break existing content).
  • Concern that HTML specs and related processes have become messy, slow, and sometimes break backward compatibility.

Web Components: benefits and deep skepticism

  • Fans like:
    • Being able to define custom elements that work across frameworks and in plain HTML.
    • Encapsulation via Shadow DOM and ES modules.
    • Use in component libraries and complex apps (often with Lit) without build steps, in principle.
  • Critics argue:
    • Design ignored real-world framework experience and userland evolution.
    • Specs are complex, brittle, and spawn more specs to fix Web‑Component‑specific problems.
    • Poor fit as fundamental building blocks for modern frameworks (eager rendering, weak SSR story, awkward composition, Shadow DOM surprises).
    • Ecosystem leaders who once pushed Web Components have moved away from them.
  • A niche where many agree they help: encapsulated widgets and custom form controls, somewhat like safer, smaller iframes.

Frameworks, ecosystem churn, and compatibility

  • Strong frustration with JS frontend’s complexity: many layers (bundlers, linting, TS, build/transpile) and frequent paradigm shifts (classes → hooks → server components).
  • Others counter that all ecosystems evolve, and JS is not uniquely bad compared to, e.g., Python packaging or breaking changes in other stacks.
  • Broader concern that JS libraries and tools rarely prioritize stable, shared interfaces, leading to “internal incompatibility” and painful upgrades.

Reactivity, observables, and overlapping primitives

  • Agreement that “reactivity” and reconciliation are real problems, but no consensus design yet.
  • Signals, observables, streams, and other reactive primitives risk overlapping, incompatible standards.
  • Some welcome browser‑level observables; others fear proliferation of near‑duplicate ways to “hear about changes.”

WASM, native apps, and the web’s role

  • Some wish browsers just ran native binaries; others point to past plugin failures and security issues.
  • Consensus that DOM operations dominate UI performance; WASM mainly helps for heavy computation, not typical reactive UIs.
  • Tooling for WASM is seen as improving but still inferior to native; cross‑compiling workflows exist but feel clunky.