[9oliYQjP]

Just curious about your wording. Why do you say this is the cheater way? It might stop working for large values of num where the anonymous function scheduled by the setTimeout begins executing before the for loop finishes. But it's certainly valid for a particular range of values.

EDIT: On second thought, does anyone even know if the scenario I mentioned above is plausible? I changed the alerts to console.logs and I'm finding it pretty damn impossible to not get the expected results using the "cheater way" even for large values of num.

[chc]

It's cheating because the point of the "challenge" is to see if you understand how scope works in Javascript — particularly with loops and closures, which confuse a lot of people — and how to use it properly. This "cheating" solution simply sidesteps the whole question by having the closures mutate a variable that the rest of the function doesn't touch.

And no, I don't think the potential problem you see is much of a problem at all. The function will keep executing even if the timers fire. As long as the timeouts execute in order and the countdown function is able to queue them in less time than they take to execute, it will work.

[bitanarch]

That depends on how the setTimeout() actually schedules things in the JavaScript engine. Recall that JavaScript is (before Chrome and worker threads appeared) traditionally single threaded - normally, even when you say setTimeout(fn, 0) - it's just putting your fn()'s execution at the end of the run loop - or whatever the scheduler calls its list of things to do. So, even though your current execution slice in the run loop may take like 1 minute, your fn() will still not execute until you're done what you're currently doing.