Prelude
Sooo…three years later and I’m finally getting around to posting something. I’ve always kept a strong pipeline of articles to read and conference talks to watch, but I eventually end up forgetting all the cool things I learn. I didn’t really take any notes or, if I did, they were always in my trusty moleskine which wasn’t really too searchable ): . Thus came the idea to use the blog as my notebook :D, so here we are…
DISCLAIMER: These notes are meant to be short and as jump off points for deeper refreshers when necessary
Actual notes :D
-
requestAnimationFrame allows you to schedule actions (e.g. animation) to occur with the next layout/paint cycle of the browser event loop
-
Animations scheduled using a timer (i.e.
setTimeout), should instead switch to usingrequestAnimationFrame -
requestAnimationFrameallows you to sync your animations with the refresh rate of the client’s monitor, thereby eliminating extra work that may be done or missed when usingsetTimeout -
setTimeoutmay be doing mistimed work because its callback is executed as part of the browser event loop’s task queue. The task queue gets processed after a frame paint and after the javascript execution stack is empty. Since you can’t tell how long it would take for the stack to empty, you cannot be certain that your work scheduled withsetTimeoutwill be executed within the current frame. Put another way, you cannot be certain that your animation will execute before the next paint. This skip in animation work can cause jank for your users. -
If the interval you set for
setTimeoutis less than the refresh rate of a user’s monitor, you may be doing more work than a user’s monitor can actually display to them -
requestAnimationFrameis also battery friendly because it doesn’t run unless its browser window/tab is active. -
A use case for
requestAnimationFrameare scroll/resize related animations, e.g. parallax effects.rAFhelps avoid jank if you are doing expensive DOM mutations in your scroll event handlers