Just In Time Compilers.

The code that you write, isn't actually the code that is run. The Just-In-Time Compiler decides how best to compile that JS to (presumably some machine/byte) code.

// use irhydra https://mrale.ph/irhydra/2.bak/
for (let index = 0, sum=0; index < array.length; index++)  sum+= var.foo(i);
return sum;

Micro optimisations within JS are totally unreliable. There's no way to know ahead of time what JIT engine is compiling the JS.

// How will the JavaScript Engine treat these?
for(var=i=0; i<len; i++>){}
||
for(++i <len){}
// We cannot know ahead of the client...

requestAnimationFrame

requestAnimationFrame runs at the first available moment of each frame.

let framesPerSecond = 1000/60
let browserOverheadHouseKeeping=6;
(framesPerSecond-browserOverheadHouseKeeping)=10;//ms

Keep JS to 3-4ms at max. This browser also has to do other pixel pipeline calculation. IE Style, Layout, Paint, Composite...

JS->Style->Layout->Paint->Composite

// In the time before requestAnimationFrame...
setTimeout(() => console.log("Bang!"), 100) &&
  setInterval(() => stopHittingYourself(), 100);
/**
 * The problem with both functions is that the JS engine pays zero attention to the rendering pipeline when scheduling these.
 * they're good functions to use when you want to wait some time to elapse ||
 * do some repeated task every so often
 *
 * They're not good for animation or time-sensitive tracking
 */
function animate() {
  // do something here
  requestAnimationFrame(animate);
}
//
requestAnimationFrame(animate);