Menu
In John Resig's book "Secrets of the Javascript Ninja", he makes the following assertion:
Programming for the browser is no different, except that our code isn’t responsible for running the event loop and dispatching events; the browser handles that for us.
Our responsibility is to set up the handlers for the various events that can occur in the browser. These events are placed in an event queue (a FIFO list; more on that later) as they occur, and the browser dispatches these events by invoking any handlers that have been established for them.
Because these events happen at unpredictable times and in an unpredictable order, we say that the handling of the events, and therefore the invocation of their handling functions, is asynchronous.
I am having a hard time accepting the use of the term asynchronous here. Doesn't he really mean achronological? They may also be asynchronous, but not for the reasons presented to support this statement. Thoughts?
680
Event handlers are really a form of asynchronous programming: you provide a function (the event handler) that will be called, not right away, but whenever the event happens.
That's correct. All event handlers are fired synchronously and in order of binding.
Event loops run asynchronous tasks and callbacks, perform network IO operations, and run subprocesses. Application developers should typically use the high-level asyncio functions, such as asyncio.
Event handlers are not Dispatched Asynchronously So even though you're making an await call, the source thread is the Main UI thread. So you actually may still be blocking even though your event handler is async .
Your question title and your question body seem to be asking two different things. I'll try to address both.
The Body Question
asynchronous is not a term that John coined or even a JavaScript specific term. It has a established meaning in computer science. And although what John says is accurate, I think it's incomplete. He is correctly explaining why we use the term asynchronous (the etymology), but not explains what asynchronous programming is.
In computer science, asynchronous means suspending executing code, allowing other (arbitrary) code to run in the same thread, and eventually resuming the suspended code. There are many techniques for accomplishing this and many ways of abstracting this for the programmer, but they all share the trait of suspending code rather than blocking. This is utilized to avoid blocking an entire thread while waiting for some slow resource (like an HTTP request, a file, or a database).
For example, if you were to make a synchronous HTTP request, then no other JavaScript could run until the request completes. So any part of the web page that depends on JavaScript would be frozen. However, if you make an asynchronous HTTP request, the code making the request can be suspended while it waits on the request. This allows other code to execute. And after the HTTP request is complete, the request code can resume.
The reason John says asynchronous code can happen is any order is because we don't know when external resources will be available. For example, if you make two or more asynchronous HTTP requests, there is no way to know in what order the requests will complete (consequently, what order the code will be resumed).
The Title Question
Browser events are asynchronous in the same way our example HTTP request is. In fact, in many ways the user as just an other external resource. The user will do things on their own time, asynchronous of what code is currently executing.
For example, if your code defines a handler for the click event of a button on the page. Your JavaScript code doesn't wait on the user to click the button. It suspends that code for the click handler and executes it later when the user clicks the button. This gets to the heart of why asynchronous programming is so important in JavaScript. If your code simply blocked (waited) until that HTTP request was complete, the user could not click the button. And if your code blocked while waiting on the user to click something, then your HTTP request would timeout.
Final Thoughts
In JavaScript, we don't often think suspending and resuming code. In fact you can't just suspend in the middle of an running block of code. The block will always complete before anything else is executed. Instead we pass callbacks out of our code block to be executed later. These callbacks can take along with them access to resources (scope) from the original code block. The callback is what is resumed from the original context.
This is a good resource if you want to dive deeper in to how JavaScript manages Concurrency model and Event Loop. Also, JavaScript has added some powerful abstractions to the event loop beyond callback, such as Promises and Generators. These are worth spending some time on.
80
The way it's worded, I think it's technically correct (and you may disagree) albeit confusing. I would have worded it differently since it seems to indicate that your JavaScript execution call be preempted.
the invocation of their handling functions, is asynchronous.
The invocations of handlers (done by the browser itself, probably in C or C++, not JavaScript) does happen asynchronously, that is, there are other threads that add events to the queue, meaning that the event loop is preempted.
He did not say that the handlers execution is asynchronous. Those are guaranteed to run to completion and not be preempted (by other JavaScript).
I think another thing that is bothering you is
Because these events happen at unpredictable times and in an unpredictable order,
This is not saying that no events run in a predictable order but some do, so it's technically also correct but misleading as you showed with your setTimeout example. For example:
Also note that if you do fire a synthetic event, or call click() on an element, all its handlers will be called immediately (jumping the queue), a new event does not go into the queue.
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
