When to use requestAnimationFrame?

Question

Having discovered requestAnimationFrame just a moment ago, I have dived into all the information I could find about it. To name just a few of the resources I came across in case there are others looking for more info about it:

• http://creativejs.com/resources/requestanimationframe/ - explains the basics about it.
• http://www.html5rocks.com/en/tutorials/speed/animations/ - explains how to use it.

Anyway, all of these resources tell me something about how requestAnimationFrame works or how it could/should be used, but none of them tell me when it is right to use it.

• Should I use it for animations (repeated changes to the style of an element, much like CSS animations)?
• Should I use it when an automated event wants to change the css/classes of one or multiple elements?
• Should I use it when an automated event wants to change the text value of one or multiple elements? (e.g. updating the value of a clock once every second)
• Should I use it when an automated event wants to modify the DOM?
• Should I use it when an automated event needs values like .offsetTop, .offsetLeft and then wants to change styles such as top and left a few lines further?
• Should I use it when a user generated event causes any of the above changes?

TL;DR: When is it right to use requestAnimationFrame?

Answer 1

You shouldn't yet. Not really, at least. This is still experimental and may or may not reach full recommendation (it is still a working draft at this point). That said, if you don't care about older browsers, or willing to work with the polyfill available the best time to use it is when you are looking to draw things to the screen that will require the browser to repaint (most animations).

For many simple modifications of the DOM, this method is overkill. This only becomes useful when you are doing animations when you will be drawing or moving items quickly and need to make sure that the browser repainting is keeping up enough to make it smooth. It will allow you to ensure that every frame you calculate will be drawn to the screen. It also provides a utility for more accurate time measurements to your animations. The first argument is the time at which the paint will occur, so you can ensure that you are where you should be at that moment.

You should not use it when you are doing many simple modifications to the DOM, or things that don't need to be smoothly transitioned. This will be more expensive on your users' computers so you want to limit this to making things smoother in transitions, movements and animations. Forcing a frame redraw is not needed every time you make a change on the page, since the response will be fast enough most of the time you don't need to worry about that extra couple milliseconds between draws.