JavaScript Event-Loop

Every JavaScript developer encounters this at some point, but it can be tricky to grasp at first. As a visual learner, I wanted to make it easier for you by explaining it with simple, low-res GIFs. 

But first, what is the event loop and why should you care?

JavaScript is single-threaded, meaning it can only execute one task at a time. Normally, this isn't an issue, but imagine running a task that takes 30 seconds. During that time, everything else is blocked, making the UI unresponsive since JavaScript runs on the browser’s main thread by default. No one wants a sluggish, frozen website.

Luckily, the browser gives us some features that the JavaScript engine itself doesn’t provide: a Web API. This includes the DOM API, setTimeout, HTTP requests, and so on. This can help us create some async, non-blocking behavior 🚀

When a function is invoked, it gets added to the call stack, which is part of the JavaScript engine and not specific to the browser. The call stack operates on a "last in, first out" principle (like a stack of pancakes 🥞). Once a function returns a value, it is removed from the stack 👋.

• Functions get pushed to the callback when they're invoked and popped off when they return a value.

The respond function returns a setTimeout function, which is provided by the Web API. This allows us to delay tasks without blocking the main thread. The callback function passed to setTimeout, () => { return 'Hey' }, is added to the Web API. Meanwhile, both the setTimeout function and the respond function are removed from the stack after returning their values.

• setTimeout is provided to you by the browser, the Web API takes care of the callback we pass to it

In the Web API, a timer runs for as long as the second argument we passed to it, 1000ms. The callback doesn’t immediately get added to the call stack, instead, it’s passed to something called the queue.

• When the timer has finished (1000ms in this case), the callback gets passed to the callback queue

This can be a confusing part: it doesn't mean that the callback function gets added to the call stack (thus returns a value) after 1000ms! It simply gets added to the queue after 1000ms. But it’s a queue, the function has got to wait for its turn!

 Now comes the moment we’ve all been waiting for—the Event Loop in action! Its sole job is to connect the queue with the call stack. If the call stack is empty—meaning all previously invoked functions have returned their values and been removed—the first item in the queue moves to the call stack. In this case, since no other functions were running, the call stack was empty when the callback function reached the front of the queue.

The callback is added to the call stack, gets invoked, and returns a value, and gets popped off the stack.

Reading an article is helpful, but true mastery comes from hands-on practice. The more you work with it, the more comfortable you'll become. Give it a try—can you predict what will be logged to the console when running the following code?

const alpha = () => console.log("A");
const beta = () => setTimeout(() => console.log("B"), 300);
const gamma = () => Promise.resolve().then(() => console.log("C"));

alpha();
beta();
gamma();
console.log("D");

Got it? Let's quickly take a look at what's happening when we're running this code in a browser:

• "A" is logged immediately since alpha() is a synchronous function.
• beta() sets a setTimeout for "B" with a 300ms delay and moves on.
• gamma() returns a resolved Promise, placing "C" in the Microtask Queue.
• "D" is logged next because it's part of the main execution thread.
• The Microtask Queue (higher priority) executes "C" before the Macrotask Queue, so "C" logs before "B".
• Finally, "B" is logged after 300ms from the Callback Queue.

That's all for this article now.

Hope you like the article. Stay Tuned for more.