The most common syntax for using an anonymous function with JavaScript’s setTimeout has never sat well with me. For a quick, non-reusable bit of code that needs to run after some interval, you’ll often see something like this:

That works, but the placement of the closing curly brace makes the delay awkward to scan for and the code’s overall structure unnecessarily difficult to parse at a glance. That effect is exacerbated when the body of the anonymous function is more than just a line or two of code.

In this post, I want to briefly show you an simple alternative that I think is more readable and maintainable.

A real-world example

An example with several lines of code inside the callback helps illustrate how that common setTimeout format can be tedious to read at a glance. For example, let’s take a look at a snippet that I’m running here on this site to gently nag visitors who block the Carbon ad in my sidebar.

At the time of this post, it started out as something like this:

After the page has finished loading all of its assets, which fires the window’s load event, the tiny ad I display from Carbon is almost always already loaded. At that point, most ad blocking extensions will have prevented Carbon’s JavaScript from loading and injecting an ad:

The #azcarbon div remains empty after the page loads when ad blockers are running.

#azcarbon remains empty after the page loads when ad blockers are running.

So, I can determine whether the ad was able to load or not by testing the placeholder div’s .html() property for emptiness.

Unfortunately, that approach infrequently generates false positives. When a visitor returns to a page with every asset already cached locally, the window’s load event may fire more quickly than Carbon’s JavaScript can be loaded.

Using setTimeout to avoid false positives

I was hesitant to nag people about ads in the first place, so the last thing I wanted to do was nag visitors who are not actually blocking the ad. To avoid those false positives, I decided to introduce a slight delay after the window load event before looking for ad content in the #azcarbon placeholder.

Since ad blockers prevent the Carbon script from even loading, I don’t have the opportunity to do something like monkey patch Carbon’s JavaScript to add my own callback when it fails to load an ad. So, the a compromise I’m using for now is to wait a few seconds after the window load event before looking inside #azcarbon.

You would often see that sort of delay written in an inline anonymous function parameter to setTimeout, like this:

Tossing the code in an anonymous function and using that as the setTimeout parameter works, but I think it’s ugly.

Improving the syntax

That trailing parameter to specify the number of milliseconds to delay execution is what really bothers me. At a glance, that’s not very readable. It reminds me of jQuery’s .hover(in, out) that you can never make read well with inline anonymous functions.

Instead, we can take advantage of how functions are just like any other variable in JavaScript. In my eyes, defining the function separately and then making the setTimeout call in a single line makes things much more clear:

Even without any code comments, this approach is clearly more readable in my eyes. Now, the 5,000 millisecond delay is on equal visual footing with the action to be performed, instead of being tucked away in a scramble of punctuation.

Be careful not to prematurely execute the callback

A common mistake when using functions as parameters accidentally executing the function immediately instead of passing it in as a reference:

That might look similar enough to the previous example, but doesn’t work the same way at all. Instead, this will immediately execute adNag and pass its return value (undefined) to setTimeout for later execution.

In this case, that means #azcarbon‘s content’s will be checked when the window’s ready event fires and nothing at all will happen five seconds later when setTimeout attempts to invoke undefined.


Taking advantage of JavaScript’s functional nature is a great way to help mitigate some of the language’s potential for being difficult to maintain. Any time you can boil code down into functional chunks (a similar approach works well to clean up switch statements too), I think that lends itself to better readability and maintainability over the long run.

What do you think? Doesn’t the latter example read a lot better than the inline function? Do you do something similar, different, or better to improve your setTimeout code?