News for hackers. Stuff that matters.
Re:Asm-dom, a minimal WebAssembly virtual DOM to build C++ SPA by imtringued on Monday March 16, 2020 @07:34AM (#22591802)
It's all about batching. Sometimes doing a tiny change can cause the entire page to re-render. If you render your templates directly to the DOM you might start a rerendering chain that needlessly wastes performance. The other benefit is that the vDOM reduces the number of changes to a minimum. That's good but it's the rendering that kills performance. Changing 1000 or 10 DOM nodes doesn't matter that much.
Re:Asm-dom, a minimal WebAssembly virtual DOM to build C++ SPA by infogulch on Monday March 16, 2020 @09:39AM (#22592536)
We don't need vDOM, we need a batching/transaction interface to the normal DOM.
Re:Asm-dom, a minimal WebAssembly virtual DOM to build C++ SPA by tannhaeuser on Monday March 16, 2020 @10:33AM (#22593038)
DOM already has a "batching" interface: construct an arbitrary complex new node off-screen, then use eg. replaceChild() on the live DOM (possibly using importNode()/adoptNode()) to attach it as the last step of your event handler.
Re:Asm-dom, a minimal WebAssembly virtual DOM to build C++ SPA by lhorie on Monday March 16, 2020 @12:45PM (#22594312)
That has two problems:

1) this technique doesn't work if you need to keep part of the DOM (e.g. a focused input or a running video)

2) this technique is O(n) in IE

Re:Asm-dom, a minimal WebAssembly virtual DOM to build C++ SPA by jlokier on Monday March 16, 2020 @03:47PM (#22596790)
This technique should be O(n) in every browser (where n is the size of the inserted tree), unless large parts of the tree are hidden with display:none.

After replaceChild(), the inserted tree must be analysed in context for CSS, layout and rendering. That will take O(n) unless parts can be skipped.

Do you mean that IE does a separate CSS or layout calculation for each node as they are inserted one by one?

Re:Asm-dom, a minimal WebAssembly virtual DOM to build C++ SPA by austincheney on Monday March 16, 2020 @10:00AM (#22592737)
> Sometimes doing a tiny change can cause the entire page to re-render.

What kind of change? If you are talking about repainting the visual CSS rendering to the viewport that isn't the DOM. That is your hardware. This is why modern browsers use GPU acceleration.

Changes to the DOM are changes to the DOM tree and the markup represented by that tree. These changes can have second order performance implications if the change to the tree results in adding/removing many nodes of it results in execution of events, which is outside the DOM, that result in the execution of additional DOM instructions.

> If you render your templates directly to the DOM you might start a rerendering chain that needlessly wastes performance.

I have never encountered this. Could you provide an example?