I’ve been experimenting with an idea in order to play well with graphic performance: http://npmjs.com/raf-timeout
I think it’s a good idea for performance, and it will work with most apps (as long as they have rAF). In rare cases, an app might need setTimeout or setInterval to fire exactly as expected, but for most apps, the -+16ms inaccuracy introduced by using requestAnimationFrame is negligible.
Assuming display’s refresh rate is always 60 Hz is probably a dead-end road since the rate may actually be different — e. g. 50, or 75, or 120, or 144 Hz, or any else — according to what the specific display is capable of.
Well, the idea is that, for most code, the refresh rate doesn’t really matter. Usually, timeouts are approximate. If the refresh rate is higher than 60hz, then it only means the timeout will be more accurate. In my use cases, I think the benefit with respect to graphics outweighs the loss of accuracy (or is it precision?).
Yeah, using a timeout function that’s as responsive to browser workload as possible is ideal. You’re right that most of the time a rAF is acceptable; you should also look into requestIdleCallback for when your latency needs are even lower.