It's really surprising that people put faith in virtual Dom implementations, when browsers have been optimized for decades for efficiency. With the right batching strategy that minimalistic libraries like FastDom [1] offer, there's no real reason to use the virtual Dom.
A frequent argument for the use of vdom has been that it reduces Dom trashing. I am willing to bet that if a vdom library has figured out what elements don't need updating, the browser's Dom implementation tuned over decades has that logic built-in. So go ahead and trash the Dom, but batch your updates and the browser's logic will likely not trash more than necessary. And since that logic is implemented in an AOT compiled language, it probably is much faster than a js v-dom
I was waiting for someone to post this. We have tried hyperhtml, various VDOM implementations like Vue and React, but nothing compares for our complex app. We use FastDOM however we are starting to realize it may in fact be causing some issues with write conflicts with third party scripts requiring DOM mutations. That said requestAnimationFrame which FastDOM also uses, can be majorly helpful for any thrashing. Curious what Rich thinks of FastDOM library or while I'm at it his opinion on (not a UI)..https://meiosis.js.org/
People used to look at me like I was crazy when I told them that React is nice, but you can actually write faster code with alternative methodologies. It seems like other engineers are coming around to this and creating these faster alternatives.
React made writing frontends generally better, but often slower and as rich_harris points out that it entails a lot of developer work to build and use optimizations to speed it up.
I like it. You can only hide so much comlexity in 600 bytes. Something like fastdom could probably facilitate what I'm talking about. Basically don't bother diffing, but only actually touch the DOM once per frame. So I guess in that case you'd have tons of "phantom writes" to fastdom as the state is reactively updated.
A frequent argument for the use of vdom has been that it reduces Dom trashing. I am willing to bet that if a vdom library has figured out what elements don't need updating, the browser's Dom implementation tuned over decades has that logic built-in. So go ahead and trash the Dom, but batch your updates and the browser's logic will likely not trash more than necessary. And since that logic is implemented in an AOT compiled language, it probably is much faster than a js v-dom
[1]: https://github.com/wilsonpage/fastdom