<story><title>Virtual DOM is pure overhead (2018)</title><url>https://svelte.dev/blog/virtual-dom-is-pure-overhead</url></story><parent_chain><item><author>c-smile</author><text>Yes and no.&lt;p&gt;Having implemented virtual DOM natively in Sciter (1), here are my findings:&lt;p&gt;In conventional browsers the fastest DOM population method is element.innerHTML = ...&lt;p&gt;The reason is that element.innerHTML works transactionally:&lt;p&gt;Lock updates -&amp;gt; parse and populate DOM -&amp;gt; verify DOM integrity -&amp;gt; unlock updates and update rendering tree.&lt;p&gt;While any &amp;quot;manual&amp;quot; DOM population using Web DOM API methods like appendChild() must do such transaction for any such call, so steps above shall be repeated for each appendChild() - each such call shall left the DOM in correct state.&lt;p&gt;And virtual DOM reconciliation implementations in browsers can use only public APIs like appendChild().&lt;p&gt;So, indeed, vDOM is not that performant as it could be.&lt;p&gt;But that also applies to Svelte style of updates: it also uses public APIs for updating DOM.&lt;p&gt;Solution could be in native implementation of Element.patch(vDOM) method (as I did in Sciter) that can work on par with Element.innerHTML - transactionally but without &amp;quot;parse HTML&amp;quot; phase. Yes, there is still an overhead of diff operation but with proper use of key attributes it is O(N) operation in most cases.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;sciter.com&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;sciter.com&lt;/a&gt;</text></item></parent_chain><comment><author>ttfkam</author><text>innerHTML doesn&amp;#x27;t preserve event handlers. So you&amp;#x27;re either reassigning event handlers over and over or relying on delegate handlers everywhere.&lt;p&gt;And while your statement makes intuitive sense regarding performance, actual measurements show clearly that idiomatic Svelte (and other modern frameworks) routinely beat VDOM-based efforts handily in their idiomatic cases and often even when folks jump through the performance optimization hoops needed for VDOM.&lt;p&gt;VDOM is pure overhead. Better than manually aligning writes before reads manually a la 2010, but noticeably worse than the current crop of compiled offerings.</text></comment>
<story><title>Virtual DOM is pure overhead (2018)</title><url>https://svelte.dev/blog/virtual-dom-is-pure-overhead</url></story><parent_chain><item><author>c-smile</author><text>Yes and no.&lt;p&gt;Having implemented virtual DOM natively in Sciter (1), here are my findings:&lt;p&gt;In conventional browsers the fastest DOM population method is element.innerHTML = ...&lt;p&gt;The reason is that element.innerHTML works transactionally:&lt;p&gt;Lock updates -&amp;gt; parse and populate DOM -&amp;gt; verify DOM integrity -&amp;gt; unlock updates and update rendering tree.&lt;p&gt;While any &amp;quot;manual&amp;quot; DOM population using Web DOM API methods like appendChild() must do such transaction for any such call, so steps above shall be repeated for each appendChild() - each such call shall left the DOM in correct state.&lt;p&gt;And virtual DOM reconciliation implementations in browsers can use only public APIs like appendChild().&lt;p&gt;So, indeed, vDOM is not that performant as it could be.&lt;p&gt;But that also applies to Svelte style of updates: it also uses public APIs for updating DOM.&lt;p&gt;Solution could be in native implementation of Element.patch(vDOM) method (as I did in Sciter) that can work on par with Element.innerHTML - transactionally but without &amp;quot;parse HTML&amp;quot; phase. Yes, there is still an overhead of diff operation but with proper use of key attributes it is O(N) operation in most cases.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;sciter.com&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;sciter.com&lt;/a&gt;</text></item></parent_chain><comment><author>aatd86</author><text>If you use dom fragments, in recent browsers, it&amp;#x27;s up to par.</text></comment>