156 — Event Loop, Web APIs, Task Queues (JavaScript Visualized)

Video: 156 · JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue | ~12:34 lesson | watch · Lydia Hallie

Source: this is a written companion to the video. Part of the Favorite TypeScript Videos curated path, module 00 (foundations) — the runtime mental model: 030 surveys the internals, and this video animates the async half in diagrams. Forward, 157 turns runtime understanding into a study plan.

“The event loop is a pretty notorious topic in JavaScript, but when we zoom out, it’s just a” — coordination mechanism. The runtime diagram names the five actors: call stack, Web APIs, task queue, microtask queue, event loop. JavaScript runs one thing at a time; everything asynchronous is a story about where waiting work sits and who moves it back.

the stack: synchronous code runs to completion

“So if we have the following script, we first have console log one. So a new” frame pushes, runs, and pops before the next begins. The longRunningTask demo shows the cost of that simplicity: a blocking loop starves everything — including the “Important!” task waiting behind it — which is why long work must leave the stack via APIs instead of sitting on it.

function logOne() {
	console.log("One");
}
function logTwo() {
	console.log("Two");
}
logOne();
logTwo();

the offload: Web APIs borrow the browser’s threads

“Some of these web APIs allow us to offload long running tasks to the browser.” Geolocation, fetch, setTimeout — none run on the JavaScript thread. The call registers the work plus its callback with the browser, the stack moves on, and the finished result re-enters through a queue. This offload is the physical basis of 153’s async-I/O bet.

// the stack registers, the browser works, the callback returns later
navigator.geolocation.getCurrentPosition(
	(position) => console.log("Location:", position),
	(error) => console.error("Error:", error),
);

the ordering: timers resolve by delay, not by writing

“So first, we encounter a set timeout. And this again gets added to the call stack.” The two-timer demo is the classic trap: the 200 ms timer is written first but the 100 ms callback runs first, and “End of script!” — synchronous — beats them both. Writing order means nothing; readiness plus queue position means everything.

setTimeout(() => console.log("200ms"), 200);
setTimeout(() => console.log("100ms"), 100);
console.log("End of script!");

the priority: microtasks drain before macrotasks

“Whenever we work with promises, we’re working with the micro task queue.” Then the rule that orders everything: “However, the event loop prioritizes the micro task queue.” The closing quiz — promise, timeout, queueMicrotask, sync log — resolves 5, 1, 3, 2, and the video’s final frame diagrams exactly why: the loop empties microtasks between every macrotask.

Promise.resolve().then(() => console.log("1"));
setTimeout(() => console.log("2"), 10);
queueMicrotask(() => console.log("3"));
console.log("5");

The async-model page of foundations: backward it animates the internals 030 and 101 survey, and its offload story is the theory behind 153’s platform bet. Forward, 157 assumes exactly this model when it tells learners to build projects — you cannot debug what you cannot picture.

Prev: 155 — TypeScript with Express and Node · Next: 157 — How to Learn JavaScript Fast

Transcript notes: Quotes (“The event loop is a pretty notorious topic in JavaScript, but when we zoom out, it’s just a”, “So if we have the following script, we first have console log one. So a new”, “Some of these web APIs allow us to offload long running tasks to the browser.”, “So first, we encounter a set timeout. And this again gets added to the call stack.”, “Whenever we work with promises, we’re working with the micro task queue.”, “However, the event loop prioritizes the micro task queue.”) verified against the transcript segments; the stack, geolocation, timer, and promise snippets verified against the frame captions. Screenshot refs cover 5 sampled frames in order (source frames 1, 2, 4, 6, 7): frame-0001.png (runtime diagram) through frame-0005.png (priority diagram) across the ~12:34 runtime.