Re:RE:DOM – Tiny turboboosted JavaScript library for creatin...
by pitaj on Sunday January 20, 2019 @12:52PM
(#18954349)
You have to have some ideas of what the state was before the change, and what changes need to be done to transfer states. In complex UIs, writing custom update logic for every change results in an unmaintainable mess and a large payload to the client.
Re:RE:DOM – Tiny turboboosted JavaScript library for creatin...
by baybal2 on Sunday January 20, 2019 @01:10PM
(#18954485)
Yes, but proper, technically superior ways for "data binding" and templating were around since IE6 era, just back then people were not concerned much with doing things properly with javascript as the universal presumption was "if it uses JS it will be slow invariably of amount of efforts put into it."
Re:RE:DOM – Tiny turboboosted JavaScript library for creatin...
by pkstn on Sunday January 20, 2019 @01:20PM
(#18954555)
That’s not the case with RE:DOM, since you have a single update function to make pure updates.
I usually create a requestAnimationFrame debounce to have just a single render per animation frame.
Re:RE:DOM – Tiny turboboosted JavaScript library for creatin...
by anonytrary on Sunday January 20, 2019 @02:39PM
(#18955107)
His point is that writing the single update function becomes complex when you have lots of changes to apply.
Even back in "medieval" era when YUI was the king, the practice of making getter-setter pairs with direct control over DOM elements was recognised as a preferred practice over any kind of state machine controlled page re-rendering system.
There of course was Angular.js - the prime target for React authors, against which all their claims held true.