Isn't truly asynchronous, non-blocking javascript impossible?

So, am I missing something here?

All javascript engines in popular modern browsers (as of 2011) are single-threaded.

This means while EVENTS can occur asynchronously, they are still queued (in "single-file") to be executed.

This means that all these techniques to load external javascript into an HTML page, they are real开发者_如何学JAVAly only to allow the download to happen asynchronously, the execution of the downloaded code however, always happens one (function) at a time, one file at a time.

So other "tips" I've seen on the web to breakup and execute initializing code blocks using setTimeout, that would be bogus, incorrect advice - the timer is also a single-file queue and executes only in order. With setTimeout you are just causing an out-of-order execution via the timer and allowing other events in the browser (ie. mouse clicks or keypress, etc.) to jump in the queue - that in itself might be good to have, but it's certainly not asynchronous code execution.

If I'm right, there's a bunch of bad, misunderstood advice out there that's too often repeated.

Aren't you confusing asynchronicity with concurrency? It's true there isn't any concurrency in the browser JS environment (aside from web workers, and anything the browser does internally, like I/O and rendering), but asynchronicity just means that all calls are non-blocking, and control flow always returns immediately.

Your definitions of 'blocking'/'non-blocking' aren't clear either. The wide-spread meaning of a blocking function call is that it doesn't return control to the caller until all computation, I/O, etc. has completed. This says nothing about concurrency.

AFAIK, Javascript is asynchronous in the sense that, although it runs on one thread, said thread is running concurrently to other threads executing other actions (page rendering, for instance) independently of the Javascript engine.

The definition, I think, does not mean to state that the Javacsript itself can be executed in any order - that's linear and in accordance with scope.

You're right about how JavaScript engines work in single pages, w/r/t setTimeout and such. (Generally speaking, this is a good thing because it makes writing JavaScript and reasoning about the code much easier.) In case you haven't read it, jQuery's Jon Resig wrote a solid explanation of JavaScript's timers.

Truly asynchronous JavaScript in the browser is defined by the Web Workers API.

• Web Workers (Wikipedia)
• Using Web Workers (MDC)
• John Resig on Web Workers

Setting aside the new HTML5 "web worker" facility, you're right.

Web workers are just for that. Although due to poor browser availability they might not be the solution for now.

I'm no javascript guru, so this is just my musing, but it would appear to me that you might be partially right.

However, if you think of the Javascript thread as "time" and allow other functions to jump in the flow of time wherever you need them, then it makes javascript essentially act like a non-blocking process.

On the other hand, HTML 5 defines web workers, which (if I'm understanding it correctly), IS "multi-threaded," in the sense that many can be processing at the same time.

Single thread yes, but that does not exclude async. Async processing and threaded processing are totally different. In fact, mouse clicks and key presses are usually the only thing ppl are tying to accomplish with setTimeout. Let the Gui have time to interact during number crunching.