Live data from Hacker News

Fast, Bump-Allocated Virtual Doms with Rust and Wasm

hacks.mozilla.org

61–62 of 62 posts

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#61
post #59

Earlier quoted context omitted.

Well... faster than what exactly? You have to do the virtual DOM pattern (generating new DOM state and then diffing with old state) with virtual elements. You can't compare proper virtual dom to using real DOM elements instead of virtual ones in a virtual dom pattern, it wouldn't make any sense. But there are other non-virtual-DOM ways to manage DOM state efficiently and in a maintainable manner. For example, my own…

Like I said, could , it probably depends on actual use... DOM navigation for read or update can be optimized, but depending on how it is done may not work as well. React itself is moving towards diffing against the browsers real DOM iirc. Browsers have gotten a lot better than in the past. That said, actually comparing each node for updates against large trees may be more costly than updating and diffing against a pa…

What I'm saying is outside of the virtual DOM paradigm you might not need to diff any elements at all, real or virtual, and so you wouldn't care about the performance of DOM reads, as you're not doing them.

Then it becomes a matter of DOM write performance, but that is the same for everyone assuming the native DOM API commands issued by the libraries are the same, which is a more or less reasonable assumption for well optimized libraries even if they use different paradigms to calculate what those commands should be.

Re: Fast, Bump-Allocated Virtual Doms with Rust and Wasm

#62
post #23

Earlier quoted context omitted.

Because virtual DOM is not the only way to achieve efficient DOM updates, and even within the concept of virtual DOM there could be many different ways to achieve efficient diffing (e.g. React vs Snabbdom). There is nothing special about a particular virtual DOM spec to deserve a place in web standards.

The things a VDOM get you is a simpler interface than the browser DOM, with an often faster comparison than the browser actually provides. There have been significant real browser DOM improvements since React came out, but I'm pretty sure an optimized VDOM in WASM could be faster because of issues of interaction with the real/full browser DOM. There are also side effects wrt the full/real DOM in practice. I agree tho…

Templates are faster than vdom and are a browser feature now.
Post reply on HN