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/ 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/ 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/ strong focus on granular localized updates.
Rendering the initial list takes much, much longer with the change propagation implementation than with the virtual dom one. I'd say, without benchmarking it, I see about 2 seconds or more difference. Even if the virtual dom is slightly slower at reacting to change, the time to render the latter implementation is more than enough to make me not want to choose it.