What it is
The event loop coordinates queued work for an agent, including tasks, microtasks, and browser rendering opportunities. JavaScript execution is run-to-completion within each job, while browser APIs schedule later work.
Mental model
Run one task, drain eligible microtasks, give the browser an opportunity to render, then continue. Exact scheduling has specification details and browser constraints, so treat the model as a debugging tool rather than a timing guarantee.
Why it exists
The browser needs to coordinate script, input, networking, timers, and rendering without allowing arbitrary concurrent access to the same JavaScript state.
When to use it
- Reasoning about Promise callbacks and timers
- Diagnosing long tasks and delayed input
- Designing work that yields to the browser
When not to use it
- Do not use the simplified queue model to promise exact wall-clock timing
- Do not treat microtasks as a way to hide unbounded work
Production considerations
- Break up long main-thread work
- Avoid recursively growing microtask chains
- Use workers for suitable CPU-intensive work
Accessibility implications
Long tasks can delay keyboard, pointer, and assistive-technology interactions. Responsiveness is an accessibility concern as well as a performance concern.
Performance implications
Large tasks block input and rendering. Scheduling smaller units of work can improve responsiveness, but adds coordination overhead.
Example · javascript
console.log('A');
setTimeout(() => console.log('task'), 0);
Promise.resolve().then(() => console.log('microtask'));
console.log('B');