How does JavaScript handle AJAX responses in the background?

Since JavaScript runs in a single thread, after an AJAX request is made, what actually happens in the background? I would like to get a deeper insight into this, can anyone shed some light?

Solution 1:

Below the covers, javascript has an event queue. Each time a javascript thread of execution finishes, it checks to see if there is another event in the queue to process. If there is, it pulls it off the queue and triggers that event (like a mouse click, for example).

The native code networking that lies under the ajax call will know when the ajax response is done and an event will get added to the javascript event queue. How the native code knows when the ajax call is done depends upon the implementation. It may be implemented with threads or it may also be event driven itself (it doesn't really matter). The point of the implementation is that when the ajax response is done, some native code will know it's done and put an event into the JS queue.

If no Javascript is running at the time, the event will be immediately triggered which will run the ajax response handler. If something is running at the time, then the event will get processed when the current javascript thread of execution finishes. There doesn't need to be any polling by the javascript engine. When a piece of Javascript finishes executing, the JS engine just checks the event queue to see if there is anything else that needs to run. If so, it pops the next event off the queue and executes it (calling one or more callback functions that are registered for that event). If nothing is in the event queue, then the JS interpreter has free time (garbage collection or idle) until some external agent puts something else in the event queue and wakes it up again.

Because all outside events go through the event queue and no event is ever triggered while javascript is actually running something else, it stays single threaded.

Here are some articles on the details:

• How Javascript Timers Work - written by John Resig
• Events and Timing in Depth
• W3 spec: HTML5 event loops
• MDN article on Event Loop
• Presentation on JS event queue
• The JavaScript Event Loop: Explained
• Five Patterns to Help Tame Asynchronous Javascript
• Javascript Event Loop Presentation
• Video Discussing How Javascript Works (including event loop at 10:27)

Solution 2:

You can find here a very complete documentation on events handling in javascript.
It is written by a guy working on the javascript implementation in the Opera Browser.

More precisely, look at the titles: "Event Flow", "Event Queuing" and "Non-user Events": you'll learn that:

1. Javascript runs in a single thread for each browser tab or window.
2. Events are queued and executed sequentially.
3. XMLHttpRequest are run by the implementation and callbacks are run using the event queue.

Note: Original link was: link, but is now dead.

Solution 3:

I want to elaborate a bit, regarding the ajax Implementation mentioned in answers.

Although (regular) Javascript execution is not multi-threaded - as noted well in the above answers - however, the real handling of the AJAX responses (as well as the request handling) is not Javascript, and it - usually - is multi-threaded. (see chromium source implementation of XMLHttpRequest which we'll discus above)

and I'll explain, let's take the following code:

var xhr = new XMLHttpRequest();

var t = Date.now;
xhr.open( "GET", "https://swx.cdn.skype.com/shared/v/1.2.15/SkypeBootstrap.min.js?v="+t(), true );

xhr.onload = function( e ) {
		console.log(t() + ': step 3');
    
    alert(this.response.substr(0,20));
};
console.log(t() + ': step 1');
xhr.send();
console.log(t() + ': step 2');

after an AJAX request is made (- after step 1), then while your js code proceeds executing (step 2 and after), the browser starts the real work of: 1. formatting a tcp request 2. opening a socket 3. sending headers 4. handshaking 5. sending body 6. waiting response 7. reading headers 8. reading body etc. all of this implementation is usually run's in a different thread in parallel to your js code execution. for an example, chromium implementation mentioned uses ThreadableLoader go digg-into 😉, (you can also get some impression by looking at network tab of a page load, you'll see some simultaneous requests).

in conclusion, I would say that - at least - most of your I/O operations can be made simultaneously/async (and you can take advantage of this using an await for example). but all interaction with those operations (the issuing, the js callback execution) are all synchronous.