For a long time, JavaScript’s event loop felt like a phrase people repeated without really explaining it. I could write code that worked, and I could copy an async pattern that worked, but I did not have a clear picture of what happened underneath. Then one day the model finally clicked, and a lot of confusing behaviour suddenly became predictable.
The picture that helped me starts with the call stack. Think of it as a pile of work. When a function runs, it goes on top of the pile. When it finishes, it comes off. JavaScript handles one thing at a time on that pile, which is why a long, blocking loop can freeze a page. Nothing else can run until the current work is done.
Next to the stack is the task queue, where callbacks wait their turn. When you set a timer, or when a network request finishes, the callback does not jump straight into the middle of running code. It waits in line. The event loop is the simple, patient mechanism that checks whether the stack is empty and, when it is, moves the next waiting callback onto it.
Promises fit into this picture once I stopped treating them as magic. A promise is a value that is not ready yet, with a plan for what to do when it is. Its handlers are scheduled, not run instantly. That is why a promise that is already resolved can still feel slightly delayed: the handler has to wait for the current stack to clear, just like everything else.
That ordering explains the classic surprises. Code after a promise still runs before the promise handler. A timer set for zero milliseconds does not run immediately; it waits for the stack and for anything already queued ahead of it. Once I saw timing as a queue rather than a clock, those examples stopped feeling like tricks and started feeling like consequences of a simple rule.
The mental model also changed how I write async code. I try to keep individual steps small, so the stack clears regularly and the interface stays responsive. I avoid long synchronous work in the middle of a user interaction. And when I need a sequence of steps, I prefer readable async flow over nested callbacks, because I can follow the order of work in my head.
I still get things wrong sometimes, especially around the finer details of microtasks and the exact order of mixed timers and promises. But I no longer guess blindly. I have a model I can test against: what is on the stack, what is waiting, and what the loop will do next.
The practical takeaway is to learn the loop before you lean on async shortcuts. If you can picture the stack, the queue, and the loop moving work between them, promises stop being mysterious. They become a tool you can reason about, and async code becomes something you can predict instead of something you hope works.
When I debug async code now, I start by asking a boring question: what is still running, and what is waiting? That question usually points to the answer faster than adding more logging everywhere. It also stops me from blaming the framework or the browser for what is really just an ordering problem I have not yet pictured clearly.