<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>bedatadriven</author><text>The VDom was never intended as a performance optimization over direct dom manipulation.&lt;p&gt;It is a tool to make functional reactive programming style _almost_ as performant as direct dom manipulation.&lt;p&gt;The comparison that&amp;#x27;s relevant here is, how long does it take to repaint the view if I recompute the view as a function of my state every time my state changes?&lt;p&gt;Compared to rebuilding the dom tree on every change, using a vdoms and diffing offer a huge  speedup.&lt;p&gt;Using jquery&amp;#x2F;vanilla js to update thr dom in an adhoc fashion in response to user input (when the user clicks &amp;quot;next&amp;quot;, then add a class to this dom element, remove this other element from this other random place...) has always had faster runtime, it&amp;#x27;s just more likely to be coded wrong.&lt;p&gt;FRP is an abstraction that makes writing and reasoning about correct UIs easier. Vdom is a technique that makes this  abstraction practical.</text><parent_chain><item><author>_the_inflator</author><text>The virtual DOM idea is nowadays a myth. It stems from the time when Facebook was still a Web App and was running on IE8 and IE6.&lt;p&gt;It was a decent idea to optimize for these browsers and FB&amp;#x27;s nature of featuring hundreds of comments etc. that could be updated somewhere outside your view port and cascade nevertheless into repaints and reflows. Remember the FB feed?&lt;p&gt;I also worked on virtual DOM optimizations back then for these IEs, but have long since abandoned optimizations. I take it with Svelte: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;svelte.dev&amp;#x2F;blog&amp;#x2F;virtual-dom-is-pure-overhead&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;svelte.dev&amp;#x2F;blog&amp;#x2F;virtual-dom-is-pure-overhead&lt;/a&gt;&lt;p&gt;Also Google sheets results show overall, that DOM is faster than any virtual DOM, so why produce overhead? &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;millionjs.org&amp;#x2F;benchmarks&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;millionjs.org&amp;#x2F;benchmarks&lt;/a&gt;&lt;p&gt;Virtual DOMs are a thing that people long time ago forgot why and for what technology it was invented. Then came Google Chrome and their optimizations.&lt;p&gt;For benchmarks, I think this is still the best around: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;krausest.github.io&amp;#x2F;js-framework-benchmark&amp;#x2F;current.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;krausest.github.io&amp;#x2F;js-framework-benchmark&amp;#x2F;current.ht...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Million: less than 1kb virtual DOM that is fast</title><url>https://millionjs.org/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>toxicFork</author><text>It feels nicer to use functional components with declarative state than set dom attributes imperatively.</text><parent_chain><item><author>_the_inflator</author><text>The virtual DOM idea is nowadays a myth. It stems from the time when Facebook was still a Web App and was running on IE8 and IE6.&lt;p&gt;It was a decent idea to optimize for these browsers and FB&amp;#x27;s nature of featuring hundreds of comments etc. that could be updated somewhere outside your view port and cascade nevertheless into repaints and reflows. Remember the FB feed?&lt;p&gt;I also worked on virtual DOM optimizations back then for these IEs, but have long since abandoned optimizations. I take it with Svelte: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;svelte.dev&amp;#x2F;blog&amp;#x2F;virtual-dom-is-pure-overhead&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;svelte.dev&amp;#x2F;blog&amp;#x2F;virtual-dom-is-pure-overhead&lt;/a&gt;&lt;p&gt;Also Google sheets results show overall, that DOM is faster than any virtual DOM, so why produce overhead? &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;millionjs.org&amp;#x2F;benchmarks&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;millionjs.org&amp;#x2F;benchmarks&lt;/a&gt;&lt;p&gt;Virtual DOMs are a thing that people long time ago forgot why and for what technology it was invented. Then came Google Chrome and their optimizations.&lt;p&gt;For benchmarks, I think this is still the best around: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;krausest.github.io&amp;#x2F;js-framework-benchmark&amp;#x2F;current.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;krausest.github.io&amp;#x2F;js-framework-benchmark&amp;#x2F;current.ht...&lt;/a&gt;</text></item></parent_chain></comment><story><title>Million: less than 1kb virtual DOM that is fast</title><url>https://millionjs.org/</url></story>