Understanding JavaScript Timers

You’re probably familiar with Javascript’s built-in timer functions: setTimeout and setInterval. At face value their behaviour appears straightforward and predictable. However JavaScript’s single threaded nature can cloak these seemingly innocent little features with mystery and intrigue, not to mention hidden powers which can be harnessed for the greater good…

The basics
(based on https://developer.mozilla.org)

//Executes a code snippet or a function after specified delay
var timeoutID = window.setTimeout(func, delay);

//Clears the delay set by window.setTimeout
window.clearTimeout(timeoutID)

//Calls a function repeatedly, with a fixed time delay between each call to that function.
intervalID = window.setInterval(func, delay);

//Cancels repeated action which was set up using setInterval().
window.clearInterval(intervalID)

Note 1: In place of a function you could use a string representation of the code to be evaluated, but if you do that you’ll have the eval police all over you.

Note 2: For reasons unknown to me, ECMA and W3C have consistently ignored JavaScript timers. Finally the WHATWG group draft (aka HTML 5) has come up trumps. The most interesting requirement is for optional function parameter arguments in setTimeout and setInterval – long supported by Mozilla and the webkit broswers but not by IE

//use of optional functional parameter argument (not supported in IE8)
setTimeout(alert, 1000, "WHATWG want me to do this");

What really happens

Imagine yourself as a function in a single threaded environment. Its not unlike driving along a single lane highway towards a tunnel (the function executer) with a bunch of other functions lined up behind you. There are no other threads so there are no overtaking lanes. Just before you reach the invocation tunnel a traffic cop pulls you over and informs you that you are the subject of a setTimeout call. He asks you to wait for the specified time period. Other functions will overtake and get invoked first. After you have sat out the required delay the traffic cop waves you on. But you can’t always just pull back into the road to enter the tunnel – you still have to let other functions go ahead until there is a break in traffic. This is why even a 1 ms timeout will push a function to the back of the invocation queue. The 1 ms delay is by no means certain, in fact 1ms turns out to be the minimum time you will wait.

console.log(1);
setTimeout(function() {console.log(2)},1);
console.log(3);
console.log(4);
console.log(5);
//console logs 1,3,4,5,2

Why is this useful? By enforcing a timeout (however small) you remove the function from the current execution queue and hold it back until the browser is not busy.

The most obvious benefit is that you can make long running functions (on which no other immediate function is dependent) defer execution until more urgent routines have completed. Consider a module that performs some animation based on user input. We want to log the latest user data but that aspect is less time-critical:

var processUserInput = function(event) {
    processState(getNewState(event));
    //user visible tasks, get priority....
    animateToNewState();
    solicitUserInput();
}

var processState = function(newState) {
    updateState(newState);
    //logging is low priority, make it wait
    setTimeout(logCurrentState,1);
}

In this way we enforced a sort of queuing priority system, with lower priority tasks getting wrapped by setTimeout.

In a similar vain, you can ensure that an alert message or other modal messaging device does not halt the immediate execution flow.

var a = 0
setTimeout(function() {alert("a = " + a)},1);
a += 4; //alerts "a = 4"

Note the interesting and potentially useful side effect. The alert message waits for the value of a to be updated before displaying it. In this simple example you could equally well just move the alert to bottom and achieve the same effect, but in cases where the variable (or a DOM element) operators are not rigidly defined (for example they might be event driven) this technique might be worth exploring further.

(Incidentally, I’ve read several articles in which the author claims setTimeout will allow your functions to run asynchronously. This is untrue. The firing of the setTimeout callback is asynchronous, the function itself will be invoked in line and after the current invocation queue).

Its also worth noting that the timing logistics of setInterval differ from setTimeout in the following way. In the case of setTimeout, the clock only starts ticking once the setTimeout function is invoked. Therefore nested setTimeouts will guarantee a minimum interval between callbacks.

You can try this out for yourself:

var recurse = function() {
    console.log(+new Date);
    if (recurse.counter++ == 4) {
        recurse = function() {}; //quit
    }
    setTimeout(recurse,10);
    var i = 0;
    //waste some time
    while (i++ < 10000) {
    }
}

recurse.counter = 1;

recurse();

setInterval, on the other hand, will fire each callback at precisely the originally designated time, regardless of additional delays that may have been experienced by previous callbacks waiting to re-enter the invocation queue. (I don’t think its possible to write code to prove this, since the logging function can only be invoked from the function that setInterval wraps, and even though the callback triggering is precisely timed, invocation of the function itself may be delayed for the reasons described above).

You can think of it like a train line. For nested setTimeouts with delays set to 1000ms, trains will run at a minimum of 1000ms apart. However when using setInterval every train will leave the station at precise 1000ms intervals even if a train is delayed ahead. Thus trains (or functions) can end up running back to back.

For further reading on this and other timer issues see: John Resig –  How JavaScript Timers Work
For some wonderful examples of how to fully leverage JavaScrip timers, check out Oliver Steele’s Sequentially project

• JavaScript