A native virtual DOM implementation would also drastically reduce memory overhead since browser engines could optimize diffing algorithms at the C++ level instead of requiring megabytes of JavaScript framework code to be downloaded, parsed and executed on every page load.
replyVirtual DOM is a useless abstraction, there are numerous libs that perform fine without it.
replyIt's a useful abstraction: you just build the full DOM with every change, a bit like a game engine. It makes so many things simpler.
replyIt's not a free abstraction though.
Other than quibbling over the word "template", how does that differ from what TFA is describing?
replyThe linked proposal has many "features" that would be "needed" if you frame the problem in terms of a "template api", centered around "binding" variables, and what not.
replyhttps://github.com/WICG/webcomponents/issues/1069
My proposal only adds one native function with nothing else: no new data types, no new apis.
Doesn't your proposal implicitly introduce the concept of a virtual DOM, which the browser does not have?
replyYou'd need to spec out what that looks like. It adds one new API from the users perspective but much more from the browsers perspective.
Additionally the next generation of Frameworks do not use virtual DOM. Solid and svelte do not. Vue is moving away from it. Signals are directionally where they're all heading.