Interesting article.<p>Some thoughts off the top of my head: Proxies are presented as a possible candidate to improve performance, but in conversations w&#x2F; some vdom library authors, I learned that proxy performance is far too bad to make it a viable option for high-performance vdom engines (in addition to having abysmal cross-browser support today)<p>Another issue is that observable overhead <i>must</i> be offset by savings in number of DOM operations in order for change propagation to be worth it. For example, a `reverse` operation would not benefit much, if at all, since it requires touching almost all DOM nodes in a list, and would incur worst case overhead on top of it.<p>While naive vdom can lose in needle-in-haystack scenarios, vdom libraries often provide other mechanisms (thunks, shouldComponentUpdate, per-component redraws, etc) to cope w&#x2F; those scenarios.<p>In addition, the field of vdom performance has very strong traction currently. Authors of vdom libraries often share knowledge and implementation ideas and there are now libraries than can perform faster than naive vanilla js in some cases by employing techniques like DOM recycling, cloning and static tree diff shortcircuiting, as well as libraries w&#x2F; strong focus on granular localized updates.