One DOM mutation is faster than one VDOM-to-DOM flow, though, of course, since the latter's doing the same thing plus more. The latter also uses a lot more memory, and keeps it around indefinitely unless you want to risk performance-killing deallocs and allocs later (I'm making some assumptions there—I'd expect a typical VDOM implementation's memory is rarely released, since re-building that data structure would be high cost if you need it again and largely defeat the purpose).
VDOM's also pure JS in the typical implementation, which is going to tend to be slower and (much) less memory efficient than getting the fuck out of JS and into the browser's C++ or Rust or whatever, ASAP (React's, for instance, is a big ol' tree of JS objects, AFAIK).
If you're often modifying or inserting 10,000 elements per update and can't be bothered to somehow batch those yourself, virtual DOM is probably a performance win. If the count is typically more like 1-10, it's probably overhead. In between, shit, I dunno, benchmark it.
One DOM mutation is faster than one VDOM-to-DOM flow, though, of course, since the latter's doing the same thing plus more. The latter also uses a lot more memory, and keeps it around indefinitely unless you want to risk performance-killing deallocs and allocs later (I'm making some assumptions there—I'd expect a typical VDOM implementation's memory is rarely released, since re-building that data structure would be high cost if you need it again and largely defeat the purpose).
VDOM's also pure JS in the typical implementation, which is going to tend to be slower and (much) less memory efficient than getting the fuck out of JS and into the browser's C++ or Rust or whatever, ASAP (React's, for instance, is a big ol' tree of JS objects, AFAIK).
If you're often modifying or inserting 10,000 elements per update and can't be bothered to somehow batch those yourself, virtual DOM is probably a performance win. If the count is typically more like 1-10, it's probably overhead. In between, shit, I dunno, benchmark it.