[baddox]

I'm pretty sure you're wrong. At the bare minimum, setTimeout must use a clock in another thread, since it doesn't block your primary thread code. I'm fairly sure that most of all of the JavaScript APIs that use callbacks are using additional threads, including the ubiquitous XMLHttpRequest.

[Waterluvian]

I'm not sure how the inner plumbing works. But since the queue just pops onto the stack, there's no true parallelism and therefore no optimization opportunity.

That being said, I'm not sure you're correct. There is no concern of blocking the main thread, since functions queued up via. `setTimeout()` are not tracked by some non-blocking timer. The queue is only inspected if the stack is empty. So if anything is happening, we just ignore the queue until nothing is happening. `setTimeout()` only guarantees a message will be processed after x milliseconds, not on-time.

https://developer.mozilla.org/en/docs/Web/JavaScript/EventLo...

[baddox]

You can definitely block the main thread. XHR requests can be run synchronously by calling .open() with false as the third argument. And when you do asynchronous XHR requests, the browser can and will run multiple requests in parallel. Of course, the callbacks just get added to the event queue and run one at a time to completion on the main thread. And granted, it's hard to call this an "optimization opportunity," since you should almost never make synchronous XHR requests anyway.

[Waterluvian]

True. But I'd call synchronous XHR a legacy item that you should probably never use.