Hacker News Reader

Comment by tracker1 | Hacker News Reader

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 though, nothing that requires a place in web standards at all.

View on HN

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 library uses Observables to drive precise DOM updates and works with trees holding real (not virtual) DOM elements, so it doesn't need to do any diffing at all: https://github.com/raquo/Laminar

I don't think it's a given which of these techniques would be faster, it depends heavily on the particular use case and the implementation of diffing (for virtual DOM) and Observables (for my pattern). If both are well optimized I'd expect virtual DOM to lose in a lot of cases.

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 partial abstraction.

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.

Templates are faster than vdom and are a browser feature now.

Reply on news.ycombinator.com