concept event loop in category javascript

This is an excerpt from Manning's book Secrets of the JavaScript Ninja, Second Edition.
In the event-handling phase, the event loop then checks the queue, sees that there’s a mousemove event at the front of the queue, and executes the associated event handler
. While the mousemove handler is being processed, the click event waits in the queue for its turn. When the last line of the mousemove handler function has finished executing and the JavaScript engine exits the handler function, the mousemove event is fully processed
, and the event loop again checks the queue. This time, at the front of the queue, the event loop finds the click event and processes it. Once the click handler has finished executing, there are no new events in the queue, and the event loop keeps looping, waiting for new events to handle. This loop will continue executing until the user closes the web application.
Now that we have a sense of the overall steps that happen in the event-handling phase, let’s see how this execution influences the DOM (figure 2.10). The execution of the mousemove handler selects the second list element with ID second and, by using the addMessage function, adds a new list item element
with the text "Event: mousemove". Once the execution of the mousemove handler is finished, the event loop executes the click handler, which leads to the creation of another list item element
, which is also appended to the second list element with the ID second.
As you might have figured out, the event loop is more complicated than its presentation in chapter 2. For starters, instead of a single event queue, which holds only events, the event loop has at least two queues that, in addition to events, hold other actions performed by the browser. These actions are called tasks and are grouped into two categories: macrotasks (or often just called tasks) and microtasks.
Figure 13.1. The event loop usually has access to at least two task queues: a microtask queue and a macrotask queue. Both types of tasks are handled one at a time.
![]()
On a high level, figure 13.1 shows that in a single iteration, the event loop first checks the macrotask queue, and if there’s a macrotask waiting to be executed, starts its execution. Only after the task is fully processed (or if there were no tasks in the queue), the event loop moves onto processing the microtask queue. If there’s a task waiting in that queue, the event loop takes it and executes it to completion. This is performed for all microtasks in the queue. Note the difference between handling the macrotask and microtask queues: In a single loop iteration, one macrotask at most is processed (others are left waiting in the queue), whereas all microtasks are processed.
When the microtask queue is finally empty, the event loop checks whether a UI render update is required, and if it is, the UI is re-rendered. This ends the current iteration of the event loop, which goes back to the beginning and checks the macrotask queue again.
Now that we have a high-level understanding of the event loop, let’s check some of the interesting details shown in figure 13.1:
Both task queues are placed outside the event loop, to indicate that the act of adding tasks to their matching queues happens outside the event loop. If this wasn’t the case, any events that occur while JavaScript code is being executed would be ignored. Because we most definitely don’t want to do this, the acts of detecting and adding tasks are done separately from the event loop.

This is an excerpt from Manning's book Node.js in Practice.
The setInterval method has been around for years in browsers, and it behaves in Node much like the client-side counterparts. The callback will be executed on or just after the specified delay, and will run in the event loop just after I/O (and any calls to setImmediate, as detailed in technique 14).
Figure 2.4 illustrates how each of the timer functions is positioned within a single iteration of the event loop.