JavaScript has this reputation of being “single-threaded”, and that confuses many people when they start programming with it. You see asynchronous tasks happening and it feels like everything is running at the same time. It isn’t. JavaScript still executes one thing at a time. What changes is how it manages tasks, and that is where the event loop comes in. The simplest way to understand it is this: there is a place where code actually runs, there are queues holding tasks that are waiting, and there is a mechanism deciding when each task gets executed. When you call a function, it goes into the call stack. This is basically the execution stack where JavaScript processes your code. ```js function a() { b(); } function b() { console.log("Hello"); } a(); ``` There is nothing asynchronous here. `a` goes into the stack, calls `b`, prints the message, and then both functions leave the stack. Everything happens in order. Things get more interesting when JavaScript finds something that takes time, like a `setTimeout` or an API request. If JavaScript waited for those operations to finish inside the stack, the entire application would freeze. So it doesn't wait. It delegates these tasks to the environment, like the browser or Node.js. ```js setTimeout(() => { console.log("Timeout"); }, 1000); ``` The `setTimeout` call leaves the stack almost immediately. The timer is handled outside the JavaScript engine through Web APIs. When the timer finishes, the callback does not run immediately. It goes into a queue and waits for its turn. This is where the event loop comes in. It keeps checking one thing: "Is the call stack empty?" If it is, the event loop takes the next task from the queue and sends it to the stack for execution. It keeps doing this continuously. This example surprises many beginners: ```js console.log("1"); setTimeout(() => { console.log("2"); }, 0); console.log("3"); ``` The result is: ```text 1 3 2 ``` Why? Because `setTimeout`, even with `0`, does not execute immediately. Its callback goes into the queue. JavaScript continues running the synchronous code, prints `"3"`, and only after the stack is empty does the event loop execute `"2"`. There is another detail that causes a lot of confusion: microtasks. Promises have a different priority compared to timers. ```js console.log("1"); setTimeout(() => console.log("2"), 0); Promise.resolve().then(() => console.log("3")); console.log("4"); ``` The result: ```text 1 4 3 2 ``` JavaScript finishes the synchronous code first. Then it processes pending microtasks, like Promises. Only after that does it move to macrotasks like `setTimeout`. This small difference explains many unexpected behaviors when mixing promises, async/await, timers, and events. A very common mistake happens when developers expect asynchronous results to be available immediately. ```js let data; fetch("/api") .then(res => res.json()) .then(res => { data = res; }); console.log(data); ``` This prints: ```text undefined ``` It is not a bug. The `console.log` runs before the Promise finishes. The correct approach is to use the result inside the asynchronous flow or use async/await. ```js fetch("/api") .then(res => res.json()) .then(data => { console.log(data); }); ``` or: ```js async function load() { const res = await fetch("/api"); const data = await res.json(); console.log(data); } load(); ``` The event loop is not magic. It does not make JavaScript run multiple pieces of code at the same time. It does not create real parallel execution. It simply organizes when tasks should run and makes sure everything happens in the correct order. Once this concept clicks, many JavaScript bugs start making sense. That strange feeling of “why did this run before that?” becomes much easier to understand.