HTML Web Components
Advocates of “HTML web components” see them as a standards-based way to extend HTML, favoring progressive enhancement, long-term stability, and integration with mostly server-rendered apps over heavy JavaScript frameworks. Critics counter that custom elements are awkward to use, still require JavaScript for any real interactivity, lack built-in solutions for state, routing, and i18n, and remain harder to server‑render and style than React- or Vue-based components. Much of the debate centers on where to draw the line between minimalist, HTML-first augmentation and full client-side frameworks that offer richer tooling and developer experience.
HTML Web Components vs JS Frameworks
- Supporters see custom elements as a way to “augment” native HTML rather than replace it, aligning with progressive enhancement and long-term maintainability.
- Critics argue they’re cumbersome, often need extra libraries (e.g. Lit), and still don’t address core app concerns like state management, routing, or data fetching, where React/Vue/Angular excel.
- Some see web components as especially useful for cross‑framework design systems and long‑lived enterprise UIs; others say modern JS frameworks already provide more reusable, portable components.
Shadow DOM vs Light DOM
- Light DOM / “HTML web components” are praised for being declarative, observable, and easy to progressively enhance (e.g. enhancing
<details>or<img>). - Shadow DOM is valued for encapsulation and style isolation, but many complain it complicates styling, testing, accessibility, and coordination between components, and can cause “flash of undefined custom elements.”
- Some report real-world pain: hard to style nested children, poor tooling support, and brittle interaction with ARIA and forms.
SSR, Performance, and “Render Before JS”
- Proponents claim a unique benefit: HTML web components can render useful fallback content before any JS runs.
- Others counter that React-like systems can SSR to HTML and match the hydrated UI, often with better initial UX than a bare fallback.
- SSR for web components is seen as immature, especially with Shadow DOM and incomplete browser support for declarative shadow DOM.
- Debate over what matters more: perceived render speed vs time-to-interaction and overall JS bundle size.
State, Routing, and “Batteries Included”
- Many note that web components are low-level: they don’t solve app-level concerns; you must add your own patterns or micro-libraries.
- Some embrace this for MPA/server-rendered apps (possibly combined with htmx, Turbo, etc.); others see it as a step back toward “DOM soup” and jQuery‑style wiring.
Developer Experience, Adoption, and Alternatives
- Several praise frameworks for DX, composability, and clear mental models (single render function vs lifecycle callbacks).
- Skeptics say “HTML web components” mostly appear in demos, not large production apps; lack of substantial, complex examples is called out.
- There is disagreement over whether web components are a “failed standard” or a slowly maturing layer that will outlast current JS frameworks.