Why doesn't jQuery use requestAnimationFrame?

Some browsers support requestAnimationFrame, so why not use it? After all, it's been supported since Google Chrome 10. Despite that, jQuery does not seem to be using it. I've found a bug report about it, but no real explanation was given? I'm sure the jQuery people have their reasons, though.

Why wouldn't they use this awesome API?

Solution 1:

In ticket #9381 you can read why they stopped using requestionAnimationFrame after some time.

To summarize, problems were that animations didn't run (browsers try to reduce CPU load) when window didn't have focus, which is OK if the window is hidden, but not if it is visible, just out of the focus. Furthermore, animation queues piled up and after window regained focus, things went berserk. This would require ugly changes in the code and/or changes how people add things to the animation queue. So it was decided that support is removed until there is some better way to do this.

Solution 2:

Given the other answers and objections here I wanted to test this out on a simple slideshow animation:

http://brass9.com/nature

As of 2013 the objections in other answers here no longer appear to be significant. I've added

https://github.com/gnarf/jquery-requestAnimationFrame/blob/master/src/jquery.requestAnimationFrame.js

to my existing animation code, and verified it's switching on and affecting the fade animations in use. It works reliably, even in background windows, in Chrome 30, IE 11, and FF 24. Testing Android 2.3, it appears to use the polyfill and work as expected.

jQuery 3

jQuery 3.0 integrates requestAnimationFrame. Basically, jQuery could handle it fine, but some users would call .setInterval(function() { tag.animate(, screwing it up. Thus the punt to major version release. jQuery 3 does not and will never support IE8 and below, so if you have IE8 users, stick with jQuery 1.x.

CSS Transitions

In my testing, the CPU/battery-saving claims of requestAnimationFrame are false promises. I see high CPU usage with it on, for example, long-fades. What does save CPU/battery is CSS Transitions, probably because the browser, especially mobile browsers, get to make much stronger assumptions about what you intend and what else is being asked of them, and native code is still faster than Javascript+DOM.

So if you really want to save CPU/battery, CSS Transitions are for you. IE9 and below can't handle them and there are still plenty of users out there, so consider jquery.transit and their Fallback to animate at the bottom of the page.