# JavaScript animation loop

DevFeed: [JavaScript animation loop](<https://devfeed.tech/articles/javascript-animation-loop-37297.md>)

Original publisher: [Read original article](<https://muffinman.io/blog/javascript-animation-loop/>)

Author: Stanko

Published: 2018-03-18T00:00:00Z

Content type: tutorial

Language: en

Sources: [Stanko Tadić](<https://devfeed.tech/sources/stanko-tadic.md>)

Topics: [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Three.js](<https://devfeed.tech/topics/threejs.md>), [Game Development](<https://devfeed.tech/topics/game-development.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [animation](<https://devfeed.tech/tags/animation.md>), [game-development](<https://devfeed.tech/tags/game-development.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [javascript-animation](<https://devfeed.tech/tags/javascript-animation.md>), [three-js](<https://devfeed.tech/tags/three-js.md>), [timing](<https://devfeed.tech/tags/timing.md>)

## AI overview

This tutorial explains why frame-count-based JavaScript animations can run at the wrong speed when requestAnimationFrame is delayed or throttled. It shows how to use elapsed, or delta, time to maintain movement at the intended rate, using a three.js game-animation context.

## Source excerpt

I've been really busy lately, doing both work and pet projects. At the moment I'm playing with three.js trying to clone old DOS game to JavaScript. Games (and animations in general) need animation loop in which we are going to update the scene and re-render it. Example animations are simplified and they just move a box 60px per second. But the concepts applied are universal and can be used for more complicated real life cases. Timing problem # We all know that animating should be done using requestAnimationFrame. My first attempt ended up being naive and it looked something like this: const box = document.querySelector('.Box'); // Initial position let position = 0; function animate() { // Updating scene logic // moving box for one pixel per frame // "requestAnimationFrame" is optimized for 60fps // so we should get smooth movement of 60px per second position += 1; // Render updated scene box.style.transform = `translateX(${ position }px)`; // Start next frame requestAnimationFrame(animate); } // Start animation animate(); At the first glance this looks fine. But it has one major problem. requestAnimationFrame is usually triggered 60 times per second, but often this is not the case. For example, the most browsers will pause it if tab goes to background. Busy (or low-end) CPU will also slow it down. Imagine for some reason that is does get triggered only 10 times per second.In the example bellow I faked it by using 100ms setTimeout. In that case our box will be moved by 1px every 100ms, ending up on 10px per second. This means our animation speed is relative to how many times requestAnimationFrame is called per second. That is the big timing problem we are trying to solve. Our animation should calculate the right position based on time passed, rather then just incrementing it by 1px each update. Delta time to the rescue # Now we know what to do - adjust the position based on time passed between two updates. Every time we are doing the update, we are going to calculate