What dif­fer­enti­ates front-end frame­works
Totally disagree with this.<p>Change detection is nothing but a hack to get around the fact that interacting directly with the browser DOM is very slow and blinky.<p>Imagine a world where interacting directly with the browser DOM didn't suck, then none of these libraries would exist.<p>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 <i>immediately</i>, which all sucks.
And updating a physical screen is <i>slow</i> too, double sucky.
Change detection is a technique for minimizing updates to the DOM to avoid the suckiness.<p>I implemented word processors, and I've used a technique called 'double buffering' 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'd have no need for React etc...
After decades, Chrome finally has a rational equivalent to this technique called the View Transitions API.<p>My hope is that the days of doing change detection are numbered and we can finally leave all this change detection crap behind us.