Every few years a technology arrives promising to free web developers from the churn of frameworks: reusable interface pieces that work everywhere, in any stack, without a build step or a dependency to update. Web Components made exactly that promise more than a decade ago, and for a long time they conspicuously failed to keep it. The tooling was awkward, the browser support patchy, and the ergonomics no match for the frameworks they were supposed to challenge. Quietly, though, that has changed. The browser has caught up, the rough edges have worn smooth, and Web Components are now a genuinely practical way to build reusable UI — which makes them exactly the kind of long-arc web story this archive exists to follow.
What Web Components actually are
Web Components are not a framework but a set of browser-native standards that together let you build your own reusable HTML elements. The idea is that instead of importing a component from a JavaScript library, you define a custom element — say <user-card> — that the browser itself understands and renders, complete with its own internal structure and styling. Once defined, you use it in plain HTML like any built-in tag, and it works regardless of what else is on the page.
Three underlying pieces make this possible. Custom Elements let you register a new tag name and attach behaviour to it. The Shadow DOM gives that element a private, encapsulated internal structure, so its markup and styles are sealed off and cannot leak out or be clobbered by the rest of the page. And HTML templates provide a way to declare reusable chunks of markup that are not rendered until you clone them. Together they deliver the core promise: self-contained, reusable elements built into the platform rather than bolted on by a library.
Why they disappointed for so long
If Web Components are so appealing in principle, it is worth being honest about why they spent years as a technology people admired but did not use. Early on, browser support was incomplete and inconsistent, which meant shipping them often required polyfills and workarounds that undercut the whole "just use the platform" appeal. The raw APIs were also verbose and low-level compared with the polished, expressive syntax of the frameworks of the day, so building anything substantial felt like more work, not less.
There was a deeper mismatch too. The frameworks that dominated the era offered not just components but an entire model for state, data flow and reactivity, and Web Components deliberately did not — they are a component standard, not an application framework. Developers comparing the two often concluded, reasonably, that the standard gave them less. So Web Components lingered in a familiar limbo: technically sound, genuinely standardised, and yet passed over because the day-to-day experience of using them lagged behind the alternatives. It is the same pattern of a good idea waiting for the platform to grow into it that we traced with the original AJAX panels in HTMX and the UpdatePanel.
What changed
The reason Web Components deserve a fresh look is that the conditions that held them back have largely lifted. Browser support is now broad and consistent, so the polyfills and caveats that once accompanied them are mostly unnecessary — you can define a custom element and rely on it working across the modern web. That single change removes the largest practical objection, turning them from a promising standard into something you can actually ship without hedging.
The ecosystem around them has matured as well. Lightweight libraries now smooth over the verbosity of the raw APIs without reintroducing a heavy framework dependency, giving you the ergonomics of a modern component model on top of the browser-native foundation. And crucially, the wider industry has swung back toward valuing exactly what Web Components offer: less JavaScript, fewer dependencies, and interoperability across stacks. In a landscape tired of framework churn, a component that works everywhere and depends on nothing has gone from unfashionable to quietly compelling, part of the same appetite for shipping less that we described in islands architecture and the return to shipping less JavaScript.
Where Web Components fit today
The clearest case for Web Components is the reusable, framework-agnostic component — precisely the problem they were designed for. A design system or component library built as Web Components can be dropped into any application regardless of what it is built with, which is enormously valuable in large organisations running several different stacks. A button, a modal or a data table defined once as a custom element works in every one of them, without a per-framework port. That interoperability is something framework-specific components structurally cannot match.
Where they fit less naturally is as the foundation for an entire complex application, because they remain a component standard rather than a full framework with an opinion about state and data flow. For that, a framework — or Web Components combined with a small library that supplies the missing pieces — is usually the better answer. The mature way to think about them is as a powerful, now-practical tool for the specific job of building portable, self-contained UI elements, not as a wholesale replacement for the frameworks that solve the larger problem of structuring an application. Understanding that boundary is what finally lets a long-promising standard deliver.
Frequently asked questions
What are Web Components? Web Components are a set of browser-native standards — Custom Elements, the Shadow DOM and HTML templates — that let you build your own reusable HTML elements. Once defined, a custom element like <user-card> is used in plain HTML and works in any stack, without a framework or build step.
Why weren't Web Components popular for so long? Early on, browser support was patchy and required polyfills, the raw APIs were verbose compared with framework syntax, and Web Components deliberately offered only a component model, not the state and data-flow tools that frameworks bundled. Those factors made them less attractive in day-to-day use.
Should I use Web Components instead of a framework? Use them for reusable, framework-agnostic UI — such as a design system that must work across several different stacks — where their portability is a real advantage. For building a whole complex application, a framework (or Web Components plus a light supporting library) usually fits better, since Web Components alone don't manage application state.
