You can get these advantages by using plain javascript with typed arrays.
By thunking I mean doing this from C++ code:
EM_ASM_({
window['asmDomHelpers']['domApi']['appendChild']($0, $1);
}, vnode->elm, createElm(vnode->children[i]));If the data structure is lockless, that is doable.
This is exactly what we've done with our product, Elevate Web Builder, so I can definitely attest to the fact that it is 100% correct. Our product uses a compile-to-JS transpiler and has its own layout engine, uses dynamic CSS, has update cycles to allow for efficient DOM updates, etc. The only real downside is that text measurment must touch the DOM and is really slow, so the layout engine has to perform a lot of intelligent caching and "measurement-avoidance" techniques to ensure that it measures text as infrequently as possible.
Okay, off to see what this produces... :-)
It's a little finicky to get it all to work consistently cross browser and cross platform, so good luck!
Virtual dom systems effectively work in two stages:
1) figuring out how the DOM should be updated
2) applying these changes with as few (or cheapest) DOM operations as possible
I don't expect WebAssembly will do much for step (2), as the bottleneck there is in repeatedly crossing the boundary between the javascript world and the DOM, or in the DOM operations themselves.
Step (1) is essentially just crunching (tree based) data structures. Web Assembly should be a lot faster here, because (depending on implementation) you get denser data structures, better cache locality, no garbage collection, and so on. You'll also get much more consistent performance.
For complex web applications that keep a lot of view state around (1) might be the bottleneck, but in most real world applications I expect that (2) is the bottleneck, because the browser has to do so much work in terms of layout, CSS application, and so on every time the DOM gets updated.
If you really want to get a big performance improvement you have to do much more in WebAssembly. Use only absolute positioning for DOM nodes and create your own layout engine. Don't have any CSS except for the rules needed to display what is currently visible. Do all typesetting in WebAssembly too. This means recreating much of a web browser inside a web browser, and you can then optimize the WebAssembly code for the specific needs of your web application for big performance gains.
It may sound hugely impractical, but if WebAsembly is only 10% slower than C it's viable. It means you won't have to wait for standards organizations to give new FlexBox options, or a way to dynamically adjust font size to fit a fixed rectangle, you can just solve all these problems locally. If this works it could lead to a complete "user space" renaissance.