<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>spankalee</author><text>&amp;gt; the fact that interacting directly with the browser DOM is very slow and blinky.&lt;p&gt;This is not really true, or at least hasn&amp;#x27;t been for many years.&lt;p&gt;Change detection&amp;#x27;s primary purpose is to let other code know when something has changed, and what changed. You could theoretically re-render all your DOM based on that information, and in many cases that works much better than people expect. But the DOM is stateful, and truly large trees of 1000s of nodes are too slow to update, so frameworks try to also do minimal DOM updates.&lt;p&gt;&amp;gt; The crux of the problem is that the browser immediately reflects changes to the DOM to the screen. And when you make a bunch of changes to the DOM you immediately see a bunch of changes happen, with portions of the screen being blanked out, and layout changes happening, and a whole bunch of other nasty stuff happening immediately, which all sucks&lt;p&gt;This is also not really true. The browser doesn&amp;#x27;t update the screen until an animation frame. Anything you do synchronously is &lt;i&gt;not&lt;/i&gt; rendered to the screen until code yields to the event loop. Even many async things, done on the microtask queue, block the next animation frame giving us visually atomic updates.&lt;p&gt;Lit, for instance, uses this to get async, batching rendering without unintended partial renders of the screen.</text><parent_chain><item><author>emorning3</author><text>Totally disagree with this.&lt;p&gt;Change detection is nothing but a hack to get around the fact that interacting directly with the browser DOM is very slow and blinky.&lt;p&gt;Imagine a world where interacting directly with the browser DOM didn&amp;#x27;t suck, then none of these libraries would exist.&lt;p&gt;The crux of the problem is that the browser immediately reflects changes to the DOM to the screen.
And when you make a bunch of changes to the DOM you immediately see a bunch of changes happen, with portions of the screen being blanked out, and layout changes happening, and a whole bunch of other nasty stuff happening &lt;i&gt;immediately&lt;/i&gt;, which all sucks.
And updating a physical screen is &lt;i&gt;slow&lt;/i&gt; too, double sucky.
Change detection is a technique for minimizing updates to the DOM to avoid the suckiness.&lt;p&gt;I implemented word processors, and I&amp;#x27;ve used a technique called &amp;#x27;double buffering&amp;#x27; to rerender complete pages off-screen, fast.  And then update the screen smoothly. 
If we used a proper word processor engine to display our UIs instead of a browser engine then we&amp;#x27;d have no need for React etc...
After decades, Chrome finally has a rational equivalent to this technique called the View Transitions API.&lt;p&gt;My hope is that the days of doing change detection are numbered and we can finally leave all this change detection crap behind us.</text></item></parent_chain></comment><story><title>What dif­fer­enti­ates front-end frame­works</title><url>https://themer.dev/blog/the-single-most-important-factor-that-differentiates-front-end-frameworks</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>robear</author><text>I don&amp;#x27;t see it that way.  The main need for change detection in my opinion is to remove the need to update parts of the DOM in an imperative manner.  It is fine to do that for smaller projects but when a project gets large, it becomes difficult to reason about the myriad of changes happening without a system to handle that.  I find any one of the examples in the linked post way more easy to reason about than manual DOM updates.</text><parent_chain><item><author>emorning3</author><text>Totally disagree with this.&lt;p&gt;Change detection is nothing but a hack to get around the fact that interacting directly with the browser DOM is very slow and blinky.&lt;p&gt;Imagine a world where interacting directly with the browser DOM didn&amp;#x27;t suck, then none of these libraries would exist.&lt;p&gt;The crux of the problem is that the browser immediately reflects changes to the DOM to the screen.
And when you make a bunch of changes to the DOM you immediately see a bunch of changes happen, with portions of the screen being blanked out, and layout changes happening, and a whole bunch of other nasty stuff happening &lt;i&gt;immediately&lt;/i&gt;, which all sucks.
And updating a physical screen is &lt;i&gt;slow&lt;/i&gt; too, double sucky.
Change detection is a technique for minimizing updates to the DOM to avoid the suckiness.&lt;p&gt;I implemented word processors, and I&amp;#x27;ve used a technique called &amp;#x27;double buffering&amp;#x27; to rerender complete pages off-screen, fast.  And then update the screen smoothly. 
If we used a proper word processor engine to display our UIs instead of a browser engine then we&amp;#x27;d have no need for React etc...
After decades, Chrome finally has a rational equivalent to this technique called the View Transitions API.&lt;p&gt;My hope is that the days of doing change detection are numbered and we can finally leave all this change detection crap behind us.</text></item></parent_chain></comment><story><title>What dif­fer­enti­ates front-end frame­works</title><url>https://themer.dev/blog/the-single-most-important-factor-that-differentiates-front-end-frameworks</url></story>