fokikorean.blogg.se - october 2023

If a task takes too long, the browser can’t do other tasks, such as processing user events.Changes to the DOM are painted only after the task is complete. It doesn’t matter if the task takes a long time. Rendering never happens while the engine executes a task.When the engine browser is done with the script, it handles mousemove event, then setTimeout handler, and so on. Tasks from the queue are processed on “first come – first served” basis.

The tasks form a queue, so-called “macrotask queue” (v8 term):įor instance, while the engine is busy executing a script, a user may move their mouse causing mousemove, and setTimeout may be due and so on, these tasks form a queue, as illustrated on the picture above. It may happen that a task comes while the engine is busy, then it’s enqueued. Tasks are set – the engine handles them – then waits for more tasks (while sleeping and consuming close to zero CPU).

When the time is due for a scheduled setTimeout, the task is to run its callback.

When a user moves their mouse, the task is to dispatch mousemove event and execute handlers.

When an external script loads, the task is to execute it.

The JavaScript engine does nothing most of the time, it only runs if a script/handler/event activates. That’s a formalization for what we see when browsing a page.

Sleep until a task appears, then go to 1.

execute them, starting with the oldest task.

There’s an endless loop, where the JavaScript engine waits for tasks, executes them and then sleeps, waiting for more tasks. In this chapter we first cover theoretical details about how things work, and then see practical applications of that knowledge. Understanding how event loop works is important for optimizations, and sometimes for the right architecture.

Browser JavaScript execution flow, as well as in Node.js, is based on an event loop.