12 comments

[ 3.1 ms ] story [ 48.6 ms ] thread
The requestIdleCallback approach can be a nice alternative to requestAnimationFrame or debouncing.

But note that requestIdleCallback is not supported in Safari, so you have to shim it there.

The spec is a good read: https://w3c.github.io/requestidlecallback/

I wish industry encouraged engineers more to pay attention to this kind of things, rather than to flashy bells and whistles. 30-50ms may seem insignificant, but has a huge impact on the overall experience.
1ms is significant if you're a heavy user: https://www.youtube.com/watch?v=vOvQCPLkPt4.
That would require a real-time OS, I suppose.
You only need a real-time os if you're guaranteeing maximum latency.
Which is exactly what was asked for.
“Realtime” doesn’t imply faster. In fact often the opposite. It just means certain timing constraints will be satisfied, often making explicit what the costs (tradeoffs) are.
Yes, the constraint here is 1ms.
From the video, 1ms feels real time, but with 5ms you can still notice the lag. So wouldn't it be more appropriate to say "4ms is significant"?
I think one of the issues here is how to do it with something like React without it being hacky. If you are working with React for instance, updating the DOM manually may seem very bad, so you must take care how to approach this without doing unnecessary calculations and re-renders.
Have a look at https://www.solidjs.com/

I looks very promising. Taking the best parts of React's API, but avoiding the performance bottleneck of a VDOM.

I can't believe this is 2021 and we have seriously such a title.