Ballpark guess - less than 5 years. There is the work ongoing on CSS and HTM modules at:
https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
In Why I Love TailwindWICG
webcomponents
HTML2014–2026
WICG / webcomponents
webcomponents
Web Components specifications
53Distinct people
96Mentions
0Explicit recommenders
4.5KGitHub stars
What to know before exploring
What it is
Web Components specifications
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- tc39/proposal-signals · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year96 dated mentions
Observed mentions: 2014-12-02 17:08:42 UTC to 2026-08-02 06:30:56 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 4 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 18 | 0 | 18 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 13 | 3 | 10 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Web Components
Web Components are a new browser feature that provides a standard component model for the Web, consisting of several pieces maintained in different places:
Shadow DOM
Most of the parts are now maintained in DOM Standard, called shadow trees.
Some of the parts are still remained in this repository. See Issue #661 for the progress of upstreaming those parts from the partially out-of-date Shadow DOM document.
Issues against the DOM and HTML Standard.
Issues raised in this repository.
The old issue tracker on W3C bugzilla, which is no longer used.
Custom Elements
Custom elements were upstreamed into the HTML Standard (and bits in the DOM Standard) and are maintained there.
Issues against the DOM and HTML Standard.
Issues raised in this repository.
The old issue tracker on W3C bugzilla, which is no longer used.
HTML Templates
HTML Templates were upstreamed into the HTML Standard and are fully maintained there.
CSS changes
The CSS WG works on CSS Scoping and CSS Shadow Parts, which help dealing with shadow trees with various selectors. Various other parts of CSS and its object model are also impacted by shadow trees and directly worked on in the various CSS specificaions.
Issues against the CSS WG repository.
JSON, CSS, HTML Modules
Successor to the abandoned HTML Imports, allows JSON, CSS, and HTML markup to be requested by a component. HTML Modules Spec work is being incubated upstream in whatwg/html (see PR). For new issues, please file against whatwg/html or here in w3c/webcomponents. See also the HTML Modules explainer, initial proposal, and earlier design ideas.
Issues raised in HTML Standard
Issues raised in this repository. Includes related issues for other potential module-types, such as CSS and JSON.
Old issue tracker includes a few issues filed when the feature was first proposed. Please avoid filing new issues there.
Issues
Please file issues in the most specific repository possible, per the above issue pointers. (It's often not this repository.)
Abandoned features:
HTML Imports
The current issue tracker.
The old issue tracker on W3C bugzilla, which is no longer used.
Note: HTML Modules are intended to replace HTML Imports (see above).
Read the full README on GitHubWhat Hacker News says
7 sourcesThis is fixable, using the form-associated custom elements feature that's specified in HTML. (Introduction: https://html.spec.whatwg.org/multipage/custom-elements.html#...)
However, that's only currently shipping in Chrome, despite the other browsers being positive on it.
Similar capability gaps that we're working to close are accessibility (https://html.spec.whatwg.org/multipage/custom-elements.html#..., same situation, everyone likes it, only Chrome ships so far) and focusability (https://github.com/w3c/webcomponents/issues/762, still figuring out what the solution should be).
In The Failed Promise of Web Components> Is the only thing that stops components from colliding literally naming convention? Like <fast-dropdown> != <my-homebrew-dropdown>? So it's basically a convention-based standard rather than a fixed standard?
Yup :) They decided to go for a flat namespace where all that distinguishes between components is their name. I'm guessing this already leads to collisions between different versions of the same element. And there has been an open issue for it for three years now: https://github.com/w3c/webcomponents/issues/716 And the "solution" seems to be "let's add more Javascript": https://github.com/justinfagnani/scoped-custom-elements
> I do feel I am exposing myself to some ridicule for being out of style and I regret my attitude in my original reply
It's perfectly fine :) I've been way more rude about web components before (and still am :)
Read the rest
)
> My main fear that I developed over the years is we end up developing frameworks for frameworks instead of delivering tangible results.
Indeed. That's my main gripe with web components, really: instead of providing tangible benefits to developers, they ended up being "an API primarily for library and framework developers"
Link to proposals:
https://github.com/tc39/proposal-import-conditions
https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
In Ways to make a web componentOne way web components can evolve to help this is with declarative custom elements, a feature many of the people who've worked on web components have wanted to pursue.
The idea is that you could define a custom element, with style and DOM encapsulation, purely in markup with either no script at all, or script only for progressive enhancement.
There are still a few features that need to be finalized and proposed, like Template Instantiation [1] to allow for expressions in HTML. When put together it would look something like this:
<custom-element name="x-summary" attributes="href">
<template>
<style>
::slotted(h1) { color: blue; }
</style>
<article>
<a href="{{ href }}"><slot name="title"</a>
<slot></slot>
</article>
</template>
</custom-element>
Which you ca
Read the rest
n then use like:
<x-summary href="http://...">
<h1 slot="title">Hello</h1>
<p>This article is about...</p>
</x-summary>
Combine this with HTML modules[2] so you can import these definitions and you could build reusable widgets without script, and some UAs could evolve their script settings to allow HTML modules but not JavaScript modules for a more locked down experience.
From there I'd hope we could find a way to use worklets to allow components to use script, but limit them to only the component's shadow DOM, not the global DOM, and not have default access to APIs like XHR and fetch, or other APIs used for fingerprinting.
[1]: https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
[2]: https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/maste...
> The core barrier here comes down to the different templated-rendering systems.
This shouldn't be a barrier at all. The rendering system a component uses should be an entirely encapsulated implementation detail of the component. Components should absolutely not have to use the same template system to be used together.
This is something web components get very, very correct.
> Web components are nearly useless without having a story for reactive rendering
There are libraries that address just that specific need, like lit-html which I maintain. Again, it's an implementation detail of the component.
> What we need is a browser standard for templated/reactive rendering of DOM content (data + template = DOM)
While rendering should be an implementation detail, I still agree with you here, simply because templating is such a universal need that
Read the rest
the platform should provide some primitives to help developers.
The current best proposal in this area is Template Instantiation: https://github.com/w3c/webcomponents/blob/gh-pages/proposals...
The main idea is that it lets you mark up a <template> with references that will be cloned along with the template contents. These references can then be used to dynamically update the cloned instance. You can accelerate most template systems with these primitives. It's critical because the DOM doesn't have any other way to clone a chunk of DOM along with references to specific nodes in that tree without manually walking the clone's tree.
I think you mean you can't have same element redeclared? Then yes this is still the case, and at least for now it will be - for any library that can output custom elements. Every component is a real interactable HTML element, imagine <div> or <p> would work differently. I believe there is some work for multiple component registries but I'm not tracking the progress on that. This is HTML thing - it is not a library specific problem. It might get solved eventually https://github.com/w3c/webcomponents/issues/716.
I come from python world where you have same restriction for all packages so it never occured to me as a serious problem :) We just pin ranges in libraries. And application itself pins specific versions in place.
In ING open-sources Lion, a library of accessible and flexible Web Components