Web Components Eliminate JavaScript Framework Lock-In

Original Article ↗ Hacker News Discussion ↗

Web Components are presented as a way to avoid lock-in to a single JavaScript framework by exposing UI pieces as standard custom elements that can be used across React, Vue, Angular, and others. Commenters are split: supporters like the ability to encapsulate complex, interactive or design-system components and pair them with lightweight tools like Lit, while critics highlight shortcomings such as awkward ergonomics, poor SSR support, Shadow DOM styling and accessibility issues, and the need for many additional specs. A recurring theme is that Web Components function best as a low-level interoperability layer or compile target rather than a full replacement for application frameworks, which still provide higher-level features like routing, state management, and templating.

Role and promise of Web Components

  • Seen as a standards-based way to encapsulate UI so it can be reused across frameworks (React, Vue, Angular, Svelte) or embedded as “islands” in static/SSR pages.
  • Helpful for gradual migration between frameworks or wrapping a framework-specific widget for use elsewhere.
  • Some find them excellent for leaf components, design systems, highly interactive or internally stateful widgets, and simple apps without a build step.

Limitations, gaps, and Shadow DOM issues

  • Many commenters consider Web Components “half‑baked”: awkward ergonomics by themselves, often requiring helper libraries (e.g., lit, Stencil), which reintroduces framework-like lock‑in.
  • Shadow DOM is especially contentious: hard to style from the outside, reliance on ::part, difficulty matching designer-driven layouts, and problems with forms and ARIA across shadow boundaries.
  • Linked W3C docs list many missing or painful pieces (form participation, accessibility, styling, scoped registries, etc.), suggesting many more specs are needed.
  • Some argue Shadow DOM duplicates iframes or CSS scoping poorly; a few call it a mistake that should be redesigned.

Relationship to React and other frameworks

  • Broad agreement that Web Components are low-level primitives or an “ABI,” not a replacement for frameworks that handle routing, state management, and templating.
  • One camp emphasizes React’s core value: a model where the UI is a (mostly) pure function of application state. Another counters that this pattern predates React and that JSX/templating convenience and Facebook’s evangelism were bigger factors.
  • Critiques of React: heavy, overbuilt for many apps, hooks complexity, virtual DOM assumptions that don’t match modern browsers, and “framework specialist” silos.
  • Defenses of React: mature ecosystem, strong hiring pool, SSR story, and still a good balance of power and maintainability. Alternatives (Solid, Svelte, Vue, Angular, lit) are discussed as better fits in some dimensions.

Practical use and best practices

  • Advice from practitioners using Web Components in production:
    • Prefer them for self-contained widgets; don’t build whole apps with bare Custom Elements unless you add a templating layer.
    • Consider avoiding Shadow DOM for app-level components, or using patterns (CSS parts, template viewport, base-style mixins) to ease styling.
    • Keep to one main framework per app for performance and consistency; use Web Components at boundaries when necessary.

Organizational and ecosystem considerations

  • Stack choices are heavily influenced by hiring ease, team consistency, and existing codebases.
  • Some wish for a future with fewer dependencies and more native capabilities; others see the trend moving toward more tooling and higher-level abstractions built atop both frameworks and Web Components.