5 ms·
We used this technique in the IE6 days (with settimeout nonetheless). We had a very big list that was being filtered as the user typed, and we would perform 10
by throwaway66666 8y ago
We used this technique in the IE6 days (with settimeout nonetheless). We had a very big list that was being filtered as the user typed, and we would perform 10 dom operations (they were all creating and appending elements to the dom), then timeout for 15ms, then 10 more operations, etc. If the user changed the text, we would clear the most recent timeout which would stop the chain, it was very clean actually. I suppose with requestAnimationFrame it's a bit nastier as you 'd need like a __dirtyRequestStop boolean check to break the scheduling, but probably much more elegant performance wise.
The concept behind it, is that you give "air to the UI thread to breath". Basically instead of locking it for 100ms you lock it for less at the time, which is perceivable as just a delay, rather that the window completely freezing. Users would see the list progressively be created sometimes which was cool too, gave it a feeling of "this is doing some heavy work behind the scenes" without really doing much.
documentFragment also was used for constructing the elements before appending the fragment to the main element :) I am wondering if that technique has any merit today, since it really helped back then.
What is old will be new again :)
- underwater 8y agoIt's not a new technique. The innovation in React is allowing the framework to pause render on any component boundary, and detect and redo any stale renders when inputs change.
- danabramov 8y agoAnother important part is that’s React doesn’t commit partial results until the whole update is done. So you don’t see “half of an update”. That’s the benefit of doing it inside the library. We also reuse the same scheduling architecture for waiting for network and other IO. You can watch our latest talks on Concurrent Mode that touch on this here: https://reactjs.org/blog/2018/11/13/react-conf-recap.html https://reactjs.org/blog/2018/11/13/react-conf-recap.html
- acemarke 8y agoOh, it goes back quite a bit further than that :) https://blog.codinghorror.com/is-doevents-evil/ https://blog.codinghorror.com/is-doevents-evil/
- throwaway66666 8y agoHah, of course, spoke too soon! And it's by Jeff Atwood! I got the idea back then from some game devs who used a variation of this technique (though theirs was a queue mechanism for prioritizing disk reads to speed up loading of important assets and defer the rest in the old magnetic days). Anyway, congrats to the react team, really cool. I am wondering if they plan to abstract it completely so that everyone uses it without even realizing it.
- vvanders 8y agoA lot of gamedev networking is like this too. Half making sure your game model works in a latent environment/can be extrapolated. The other half is clever tricks(particle systems! sound effects!) to make the player think something is happening when you're just waiting to reconverge the state with an authorative response from the server.
- zemptime 8y agoIt's already popping up again in some other places! (For what I assume will be until browsers get an actual scheduling api) https://www.youtube.com/watch?v=ypPRdtjGooc https://www.youtube.com/watch?v=ypPRdtjGooc