The Talk That Made Me Finally Understand How the Event Loop Works
When I first heard about the event loop, the concept kind of made sense.
I knew that Node.js is single-threaded but also very fast at the same time. It's using the event loop to handle thousands of concurrent requests. How exactly it accomplished that though, was a mystery to me.
I also knew not to block the event loop in Node.js otherwise server performance would suffer.
Everyone warned against blocking the event loop!
I was able to write asynchronous code that worked. I could also modify async code written by others without introducing new bugs (most of the time). But honestly, there were many moments where I had no idea why my code worked. 🤷🏼♂️
Understanding the event loop
The event loop was an abstract concept and I did not know what was happening behind the scenes. That is until I watched Philip's talk at JSConf EU. This fantastic talk finally made the concept click in my head.
I'm a visual learner and Philip's animated explanation of how the event loop works helped me truly understand what was happening behind the scenes.
All the dots started to connect. This talk was the final piece of the puzzle to truly understanding asynchronous code in JavaScript.
From that point on, I never looked at async code the same way again. It was a stepping stone to writing more complex asynchronous code patterns. I could confidently refactor callbacks to promises and async/await.
The number of times I reached out to Google for help reduced significantly. I didn't need Stack Overflow to hold my hand anymore and I could fix bugs all by myself.
This talk is 7 years old but is as relevant today, as it was back then. In web development, technologies are changing rapidly but the fundamentals remain largely the same. This is all the more reason to learn fundamental concepts like the JavaScript event loop.
Keep reading for my takeaways of Philip's talk, or skip to the end if you want to watch it right away.
The JavaScript runtime, event loop and callback queue
Philip starts by explaining that asynchronous functions such as setTimeout and XMLHttpRequest are not part of the JavaScript V8 runtime. These functions are part of the WebAPI provided by the browser, which also provides the event loop and the callback queue. In Node.js this is largely the same except WebAPIs are replaced by core modules (e.g: crypto, http, fs, etc.) which run in separate threads in C++ land.
The event loop is not part of the JavaScript runtime language. Instead, the event loop is provided by the environment executing your code — in the client, it's the browser and in the backend it's Node.js.
Philip then proceeds with an animated explanation of how the call stack works and what happens when we introduce blocking code in our programs. This wasn't something I hadn't known before, but it's an important refresher because next, we'll get to see how the event loop comes into play.
When you call an asynchronous function, the function runs in a separate thread until it completes. After completion, the callback function is pushed onto the callback queue. It's then the job of the event loop to grab the callback from the callback queue and push it to the stack when it's empty — which effectively runs the callback.
One thing to keep in mind is that the JavaScript runtime is single-threaded and can only do one thing at a time. The reason we can do things in parallel is that browsers and Node.js are more than just the JavaScript runtime — they come with the event loop and callback queue.
When most people talk about blocking the event loop, what they mean is having code that runs for a relatively long time and therefore occupying the call stack. When the call stack is busy, the event loop doesn't get the chance to clear the callback queue.
Philip went as far as to even build a tool that visualises the JavaScript event loop. It's fascinating to see it in action and I encourage you to play around with it after watching the talk.
