Mastering setTimeout: How JavaScript Handles Delays and Real‑World Tricks

If you already understand setTimeout, jump to section 3; sections 1‑2 can be read for fun. If you’re new to setTimeout, sections 1‑2 will give you useful insights.

1 JavaScript Runtime Environment

In a previous article about service workers, the browser JavaScript environment was described as:

Each page’s JavaScript main thread is a "Boss". The Boss is powerful, directing everything on the page, but has a limitation: it can only do one thing at a time (single‑threaded).

This illustrates the single‑threaded nature of JavaScript in the browser. In fact, JavaScript is also single‑threaded in Node.js. Without additional workers (e.g., Web Workers), how does JS handle complex operations on a single thread so that users perceive simultaneous responsiveness?

We’ll keep calling the JavaScript main thread the Boss. The Boss continuously receives tasks. To improve efficiency, it prioritizes the most urgent tasks. If you ask the Boss to "log something in 3 seconds or after a button click or after a server response," the Boss records this "pseudo‑request" in a notebook, promises to handle it, and continues its current work. Once the current work finishes, the Boss picks the earliest recorded pending task from the notebook.

The Boss’s capacity is limited. Its Promise will fulfill the task unless the Boss "dies" unexpectedly, but timing may not match the exact request.

For a serious deep‑dive into JavaScript’s runtime, see “JavaScript Execution Mechanism Explained: The Event Loop”.

2 Understanding setTimeout

Let’s rename the concepts:

JS main thread → Boss

Synchronous task → The task the Boss is currently doing

Asynchronous task (queue) → Tasks written in the Boss’s notebook

Many beginners mistakenly think setTimeout means "run a function after the specified time starts counting". From the name and observed behavior, this misunderstanding is easy.

In reality, setTimeout does the following:

After the specified delay, it adds the given function to the asynchronous task queue.

Therefore, when the delay expires, if the main thread is still busy with synchronous work, the setTimeout callback will not run immediately. Even after the main thread finishes its current work, the callback may still wait because earlier tasks could be ahead in the queue.

Even when the main thread is idle and the queue contains only the setTimeout callback, the actual execution time is not precisely the delay in milliseconds due to browser timer granularity:

IE8 and earlier: 15.625 ms

IE9 and later: 4 ms

Firefox and Safari: ~10 ms

Chrome: 4 ms

These imperfections are usually imperceptible to users. Often, setTimeout is used not for strict timing but as a graceful way to defer work:

"You can you up!" – code that respects this spirit runs harmoniously in the JS environment.

One poetic description of setTimeout: "Water benefits all things without contention." – from the Tao Te Ching.

3 setTimeout Use Cases

3.1 Replacing setInterval with Recursive setTimeout

setInterval repeatedly pushes a task into the async queue every delay. However, it can cause back‑to‑back executions when the main thread is busy. The following dialogue illustrates the difference, followed by a recursive setTimeout solution:

setTimeout(function () {
    doWhatYouWantTo();
    setTimeout(arguments.callee, 100);
}, 100);

setInterval: (covering eyes…) Wow, that code is brilliant! You win…

Using this chained setTimeout ensures at least the specified interval passes before the next timer runs, preventing consecutive executions.

3.2 Throttling Rapidly Fired Events

Some events, like window resize, fire at high frequency and can degrade performance if they trigger heavy DOM work. The following throttle implementation limits a method to run only if it hasn’t been called in the last 100 ms:

/**
 * Limit method execution frequency; only run if not called again within 100 ms.
 * @param {function} method The method to limit
 * @param {Object} context Execution context for the method
 */
function throttle(method, context) {
    clearTimeout(method.tid);
    method.tid = setTimeout(function () {
        method.call(context);
    }, 100);
}

function fnResize() {
    console.log(111);
}

window.onresize = function () {
    throttle(fnResize);
};

3.3 Restarting a One‑Shot GIF in IE

Requirement: a GIF should play once on page load and replay each time the user hovers over it. The typical approach works in Chrome but fails in IE. Adding a setTimeout to defer the src reset solves the issue:

$logo.on('mouseenter', function () { // hover to replay GIF
    var $logoImg = $(this).find('img');
    $logoImg.attr('src', '');
    setTimeout(function () { // needed for IE
        $logoImg.attr('src', _opt.logoImg);
    }, 0);
});

3.4 Delaying blur Event Handling

When monitoring input changes via keyup, paste, and cut, the pasted or cut content may not be reflected immediately. Wrapping the handling logic in a zero‑delay setTimeout ensures the latest value is read:

$('#input').on('keyup paste cut', function () {
    var $this = $(this);
    setTimeout(function () { // delay to get updated value
        console.log($this.val());
    }, 0);
});

3.5 More Uses?

setTimeout can influence execution order and timing; using it wisely lets critical code run first and can fix quirky bugs. The four scenarios above are just examples—feel free to discuss and add more applications.