Home > Software engineering >  Understanding execution of WebAPIs with setTimeout & DOM Api
Understanding execution of WebAPIs with setTimeout & DOM Api

Time:12-03

I have been working with JS for about a year now and I'm still learning it. My question is at the end.

In the first example:

console.log('Start');

setTimeout(()=> console.log('inside callback'), 0); 

console.log('End');

outputs

Start
End
inside callback

I understand that even though the timeout is 0, it still had to go to browser WebApi (setTimeout api) and immediately pushed into callback queue waiting for the main thread to be free (which is currently executing console.log('End')). Once the thread is free callback is executed & "inside callback" is printed.

Following this approach, I tried to experiment it with another WebAPI i.e DOM API.

This time, Instead of setTimeout, I used document.querySelectorAll()

console.log('Start');

console.log(document.querySelectorAll('img'))

console.log('End');

Outputs

Start 
NodeList(4) [img.bar-sm.-avatar.js-avatar-me, img.bar-sm.avatar.s-avatar--image, img, img]
End

This time we see DOM API output before END is printed.

I know the output but I want to understand the flow behind it.

Why it didn't follow the pattern like setTimeout?

Why didn't the DOM output came after "End" if it was processed on separate thread.

Did it follow the flow below:

document.querySelectorAll -> webAPI -> callback queue -> main thread

Does DOM API have to go though callback queue and wait for main thread to be empty. If so? how come we got consoles in the right order this time unlike with setTimeout

I'm still learning and would appreciate explanation a lot. Please point anything if I misunderstood. Thanks.

CodePudding user response:

The reason is that the document.querySelectorAll is a synchronous method where as the setTimeout is asynchronous.

JS scripts are being executed in the same environment that the DOM lives in, so it is not asynchronous. Asynchronous events are events that generally get sent to another environment (later to be handled by the event loop)

This is part of the concurrency model based on an event loop, which is actually responsible for executing the code, collecting and processing event. The setTimeout function is called with 2 arguments: a message to add to the callback queue, and a time value (optional; defaults to 0). The time value represents the (minimum) delay after which the message will actually be pushed into the queue. If there is no other message in the queue, and the stack is empty, the message is processed right after the delay. However, if there are messages, the setTimeout message will have to wait for other messages to be processed and For this reason, the second argument indicates a minimum time (not a guaranteed time). So, the message 'end' will be written to the console before the message in the callback 'inside callback' gets processed, because the delay is the minimum time required for the runtime to process the request (not a guaranteed time).

document.querySelectorAll is part of scripts that are being executed in the same environment that the DOM lives in, so it is not asynchronous and will be executed immediately.

DOM manipulation is synchronous. having said that, the browser's re-rendering process of the page in response to a DOM update is asynchronous. This can give the illusion of an asynchronous DOM update.

More about the JavaScript event loop - https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop

  • Related