Every developer who has worked with JavaScript has hit the same wall: the language is single-threaded, yet it handles network requests, timers, and user interactions without blocking the entire page. The magic happens in the event loop. A new course from the YouTube channel FrontendDevs1991 uses detailed animations and diagrams to walk through exactly how JavaScript manages asynchronous tasks while remaining single-threaded. The course breaks down the browser runtime into its core components: the engine, the call stack, web APIs, and two types of queues. Here is how each piece fits together.

The call stack and synchronous execution

JavaScript executes code on a single thread using a call stack. When a function is invoked, a new frame is pushed onto the stack. When the function returns, the frame is popped off. This is straightforward for synchronous code: function A calls function B, which calls function C, and the stack grows and shrinks in a predictable LIFO order.

The course makes a point to show the limitations of this model. If one function takes a long time to return — a heavy computation, a loop that runs for seconds — the entire stack is blocked. No other code can execute, and the browser tab freezes. The call stack cannot multitask. That is why JavaScript needs help from the browser.

Web APIs: JavaScript's superpowers

The browser provides web APIs — setTimeout, fetch, DOM events, the Geolocation API — that run outside the JavaScript engine. When your code calls setTimeout, the engine hands the timer to the browser's timer API, which runs in a separate thread. The call stack does not block waiting for the timer to finish. It continues to execute the next line of code. This is the first big idea: the browser runtime is not single-threaded, even if the JavaScript engine is.

When the web API finishes its work — for example, a timer reaches zero, or a network request returns data — it does not push the callback directly onto the call stack. Instead, it places the callback into a queue.

The task queue (callback queue)

That queue is the task queue, sometimes called the callback queue. It holds functions that are ready to run once the call stack is empty. The order is first in, first out. The course demonstrates this with a setTimeout example: even if you set a delay of zero milliseconds, the callback does not run immediately. It must wait for the current stack to clear.

The event loop: connecting the queue to the stack

The event loop is the mechanism that constantly checks two things: is the call stack empty? And is there a callback waiting in the task queue? If both conditions are true, it moves the first callback from the queue onto the stack, where it executes like any other function. The loop runs continuously, handling each task in turn.

This is why long-running synchronous tasks can delay callbacks from timers or click handlers. The event loop cannot grab a task until the stack is empty. The course illustrates this with a visualization of the browser's internal runtime.

Promises, fetch, and the microtask queue

The task queue is not the only queue. Promises and async/await introduce a second queue: the microtask queue. When a promise resolves, its .then() callback is placed into the microtask queue, not the regular task queue. The same applies to the callbacks behind async/await.

The difference in priority is crucial. The event loop processes all microtasks in the microtask queue before it moves on to the next task from the task queue. This happens after every single task completes, not just after the entire stack empties.

Consider a fetch request. The fetch call goes to the web API, which sends the HTTP request on a separate thread. When the response arrives, the promise resolves, and the microtask (your .then() function) is queued into the microtask queue. Once the current synchronous code finishes, the event loop empties the entire microtask queue — running every pending .then() — before it picks up the next task from the regular queue.

Starvation of the callback queue

The course warns about starvation of the callback queue. Because microtasks are checked before every new task, a stream of microtasks can keep the event loop occupied indefinitely, never giving the task queue a chance to run its callbacks. This is a real performance concern. If you chain a large number of resolved promises in a synchronous loop, the microtask queue grows continuously, and setTimeout callbacks, DOM event handlers, and other task-queued work get starved. The user interface can become unresponsive even though the call stack is technically not blocked.

Practical implications for developers

Understanding these queues changes how you write and debug async code. When you need to defer work, choosing between a microtask (Promise, queueMicrotask) and a macrotask (setTimeout, setInterval, requestAnimationFrame) has consequences.

For example, if you want to allow the browser to repaint the UI before continuing heavy work, you reach for setTimeout with a delay of zero. That callback goes into the task queue and runs after the microtask queue is drained, giving the rendering engine a chance to update the screen. If you instead resolve a promise, the microtask runs before the next render frame, potentially delaying the visual update.

The course covers real examples: using the Geolocation API, which triggers a browser permission dialog and returns a promise, and handling DOM events like clicks, which put event listeners into the task queue. Understanding where each type of callback lands helps you predict behavior, avoid race conditions, and prevent starvation.

A visual approach

What makes this course stand out is its use of detailed animations and diagrams to show the runtime in action. Instead of reading about the event loop in the abstract, you watch the call stack grow and shrink, see callbacks flow into the task queue, and observe the event loop moving them back to the stack. The visualizations also show the microtask queue draining before the next task is picked up, making the priority difference obvious.

The course is hosted on YouTube and is supported by Scrimba, an interactive coding platform. The full list of topics runs from the basics of the call stack through starvation of the callback queue, with a final look at visualizing internals inside the browser.

Why this matters

The event loop is not a theoretical nicety. It governs every piece of async JavaScript that runs in the browser — every API call, every timer, every user interaction. Misunderstanding it leads to bugs that are hard to reproduce: a timer that runs late, a UI that stutters after a promise chain, or a click handler that never fires because microtasks are consuming the loop. The course gives developers the mental model they need to write reliable async code.

JavaScript remains single-threaded. But with the event loop and the runtime's asynchronous helpers, it can orchestrate complex, non-blocking operations that feel concurrent. The key is knowing which queue your callback is going into — and why that matters.