what you described is lit-html, which might find its way to the browser:
https://github.com/WICG/webcomponents/issues/1069
In If not React, then what?WICG
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:02:44 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
13 sourcesThere is a proposal for JavaScript-based HTML templates: https://github.com/WICG/webcomponents/issues/1069
In If not React, then what?> Unfortunately, to my knowledge there isn't yet a close-to-the-metal solution for templating and data binding in HTML/JS
I'm hoping for this one:
https://github.com/WICG/webcomponents/issues/1069
In TinyJS – Shorten JavaScript QuerySelect with $ and $$What do you mean specifically when you say?
> DOM be a function of the state
I understand the benefits of the mental model, but the tooling that delivers that generally have a lot of complexity that isn't trivial to parse and understand. I think the benefit of being able to parse and understand your abstractions (ones you build yourselves or buy off the shelf like a framework) is there are always gaps in the constraints under which they had originally been designed; so you'll always need to understand how it works under the hood.
React's class-based components were simpler because the lifecycle methods were explicit, but the hook-based model is "easier"; however, the component lifecycle is still present. The demo code does look really clean, but in real life you quickly start to face the underlying complexity of the abstractions (e.g., us
Read the rest
eEffect, memoization, realizing how fine-grained your reactivity is is based on how you've drawn those component boundaries). You can write these optimizations yourself, or wait for the new auto-memoizing React compiler to land, but in all cases, the overall complexity remains the same (or is higher). And this isn't unique to React or other frameworks, and you'll always need to delve a little deeper.
I agree that the DOM APIs could be more declarative (e.g., declarative custom elements proposal [1], declarative shadow DOM, `@scope` CSS as another way to scope styles), and there is activity in that space, both in the W3 Web Components Community Group and the Open UI Community Group. I'm trying to get more involved in those discussions and I'd recommend everyone who cares about the web and how we build for it to participate.
I think the process of standardization for new features (through the proposals phases to finally landing in browsers) is the effort to raise the floor for all to build on top of. I remember when Promises were landing everywhere and feeling a little overwhelmed by what it meant to me because I was using Bluebird. Then the feeling of "maybe I can simplify what I'm doing and lean more on the platform" set in. Frameworks are a testbed for new ideas, and we can go further by trying to see what pieces we can pull out and standardize around (e.g., Signals proposal [2]), so we can go back to testing new ideas on top of that.
[1] https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
[2] https://github.com/tc39/proposal-signals
> In my view the only thing we should retain from the React era is JSX
honestly lit-html is much better and based on existing browser APIs. We should make it part of the webcomponents spec! Which is a work in progress:
https://github.com/WICG/webcomponents/issues/1069
In Web components are okayWebComponents Proposal: Add lit-HTML to the browser
15 points · Open discussionE4X had the unfortunate downside of returning actual DOM instances, which needed to be updated imperatively. That's why JSX eclipsed it, and there hasn't been a serious proposal for HTML templating in JS since then.
But maybe we can revive the general idea with a modern take: https://github.com/WICG/webcomponents/issues/1069
In VanillaJSX.comVery interesting to know, thank you.
There are template languages that extend the HTML syntax but render to valid HTML, and I imagine this kind of guarantee of future naming scheme is important to ensure the extended syntax does not have the potential to conflict with new attributes added to the HTML specs.
> proposal in the works to allow web developers to define custom attributes
Looks like this is it:
Proposal: Custom attributes for all elements, enhancements for more complex use cases
https://github.com/WICG/webcomponents/issues/1029
Searching for "dash" does bring up a thread of discussion around whether to require dashes or not.
---
I wonder if starting the custom attribute with a dash is allowed or not. Searching around, I see colon ":" and underscore "_" are OK, but dash "-" or period "." is only allowed after the first character.
Read the rest
> Any namespace-less attribute that is relevant to the element's functioning, as determined by the element's author, may be specified on an autonomous custom element, so long as the attribute name is XML-compatible and contains no ASCII upper alphas.
https://html.spec.whatwg.org/multipage/custom-elements.html#...
XML-compatible attribute name:
NameStartChar ::= ":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]
NameChar ::= NameStartChar | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]
Name ::= NameStartChar (NameChar)*
https://www.w3.org/TR/xml/#NT-NameStartChar
Salesforce does this with a combination of web components, with a patched up ShadowRoot so that code with a reference to the shadow root can't walk into the rest of the document, and a secure evaluator function related to SES (Secure EcmaScript) to limit the globals the untrusted script has access too.
The secure evaluator is wild. I think this is the heart of it: https://github.com/Agoric/realms-shim/blob/v1.1.0/src/evalua...
There's also an idea for isolated web components to solve this in the platform: https://github.com/WICG/webcomponents/issues/1002
In Show HN: Execute JavaScript in a WebAssembly QuickJS sandboxYou're absolutely correct.
(For reference, here's a long discussion in an issue: https://github.com/WICG/webcomponents/issues/814)
In Facebook just updated its relationship status with Web ComponentsIt's debatable if that's a fundamental problem. The entire Objective-C ecosystem was a flat namespace with prefixes too.
Web Components trace their history to trying to explain how the web platform itself works. HTML is also a flat namespace, and the goal was to empower developers to do all the same things the platform does and in the same way.
We hotly debated namespaces when designing the API and in the end decided to omit them but require at least one dash. You can think of the prefix kind of like the namespace in that sense. And in practice with reasonable prefixing practices we find folks rarely (if ever) collide, the same as ObjC.
(Not that things couldn't be better: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...)
In Facebook just updated its relationship status with Web Components"open-stylable" Shadow Roots · Issue #909 · WICG/webcomponents
2 points · Open discussion