Web Components: The Framework-Free Renaissance

Original Article ↗ Hacker News Discussion ↗

Reactivity, State, and What Web Components Actually Provide

  • Many argue web components offer no built‑in reactivity or data binding; you must hand‑roll reactive updates, efficient DOM patches, and templating.
  • Others point out minimal mechanisms exist (e.g., observedAttributes, events), but acknowledge they’re far from the higher‑level state systems frameworks provide.
  • Some see upcoming proposals like JS signals as a way to pair native reactivity with web components, but this is still future-facing.

Frameworks vs “Framework-Free” Narrative

  • Repeated theme: for any non‑trivial app, you quickly end up adding a framework (Lit, Stencil, etc.) on top of web components.
  • Critics say “framework‑free” is misleading: those tools are frameworks, recreating reactivity, templating, and state management.
  • Several participants stress the distinction between content-heavy “pages” (where vanilla web components can shine) and full “applications” (where frameworks are still preferred).

Shadow DOM, Styling, and Encapsulation

  • Shadow DOM is polarizing: some love scoped markup/styles and lifecycle hooks; others avoid it, preferring light DOM plus normal cascading CSS.
  • Complaints include partial isolation (CSS vars and inheritance “leak”), styling pitfalls, accessibility quirks, and layout inconsistencies with host font sizing.
  • Declarative shadow DOM and better tooling are desired but seen as immature or under‑supported.

Tooling, Ecosystem, and Interoperability

  • Tooling gaps: weaker devtools, testing pain (especially with jsdom), lack of mature patterns for large apps, poor HTML syntax highlighting in templates.
  • Web components work well as a distribution format: one UI library consumable by React, Angular, etc., via attributes/events.
  • Interop still has friction: old React versions need wrappers; Angular reactive forms need adapters; global custom element names reduce modularity.

Forms, Semantics, and Spec Politics

  • Form-associated custom elements and ElementInternals are seen as complex and incomplete; missing features (e.g., true submit behavior) block some use cases.
  • Safari’s refusal to implement certain custom‑element behaviors and concerns about spec design (e.g., Liskov substitution) add to skepticism.

Security, Quality, and the Article Itself

  • Example code in the article is flagged as XSS-prone and not aligned with best practices.
  • Some distrust the “AI wrote this” angle and the hype tone (“framework‑free renaissance”, “AI makes it easy”), seeing it as overstating current capabilities.

Real-World Experiences and Niche Strengths

  • Positive reports: complex apps (e.g., dashboards, note-taking, Home Assistant, media players) built with web components plus a light framework layer, with gradual evolution and no full rewrites.
  • Strong consensus niche: embeddable widgets, cross‑framework UI libraries, and isolated components that behave more like “missing native elements” than full app architecture.