Lit has always been designed partially as a prototype for where web component standards could go in the future. That's a big reason Lit is fairly conservative and un-opinionated. It doesn't try to undo or paper-over any of the DOM APIs, but add to them instead.

There is a proposal in TC39 for native signals, which I think would make a huge dent towards library-less reactivity.

I'm also working on a proposal for native reactive templating which would more-or-less obsolete lit-html. I wrote about the idea some on my blog:

- The time is right for a DOM templating API https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...

- What should a native DOM templating API look like? https://justinfagnani.com/2025/06/30/what-should-a-dom-templ...

▲

lenkite 7 days ago | parent | next [-]

I hope there can be ways without JS to populate templates with data - autoloaded from sources. This would tremendously increase the number of JS free web-sites. Also wish the web-components standard did not mandate the use of JS. It should be possible to define simple web-components (HTML+CS) declaratively and have this officially supported in standard and implementation

	▲	troupo 6 days ago \| parent [-]
		The irony is that the original vision of web components was what you wanted. See Alex Russels "a vision for the Future": https://web.archive.org/web/20121119184816/https://fronteers... --- start quote --- I think we're stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turning complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat. Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you'd sent markup down the wire in order to get back to the same value that was going to be provided to you if you'd done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it's stupid. Gmail does that because that's how you can actually deliver the functionality of Gmail in a way that's both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket. .... They're the sorts of things that you use when the semantic that you're trying to express is so far away from what HTML natively has a semantic for, that you're willing to go and be completely self served for it. Taking on for yourself accessibility, UI, UX, internationalization, localization, performance, theme ability; all of this stuff is mostly taken care of for you by HTML. --- end quote --- 14 years later, web components depend on JS to: - participate in forms - solve accessibility issues (not yet, but coming through a yet another JS-only standard) - SSR is still mostly tied to JS and specific JS frameworks (and Declarative Shadow DOM doesn't really solve the issue because it requires you to duplicate a lot of code). See also https://ionic.io/blog/the-quest-for-ssr-with-web-components-... - CSS modules and other imports that are moved entirely into JS etc. etc. ----- Slight off topic. From the same talk: --- start quote --- Now, we can do some of that today. We can go and look at the top million pages and figure out which JavaScript library that they're using, which features are being most heavily used, we can put those things in DOM. But is that the right place for them? It's a hard thing to figure out. --- end quote --- I wish they spent time figuring that out. We wouldn't have to wait a few decades for https://open-ui.org to slowly make its way into the browsers.

▲

7 days ago | parent | prev | next [-]

[deleted]

▲

troupo 7 days ago | parent | prev [-]

> Lit has always been designed partially as a prototype for where web component standards could go in the future.

> There is a proposal in TC39 for native signals,

Which originated (or the modern versions of signals originated) in Solid, not in Lit.

Let me quote the readme: https://github.com/tc39/proposal-signals

--- start quote ---

The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

-- end quote ---

	▲	nchmy 7 days ago \| parent [-]
		They never claimed that signals originated in lit. They were just responding to the comment that there's no native reactivity in web components...