![]() ![]() 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. One thing to keep in mind is that the JavaScript runtime is single-threaded and can only do one thing at a time. 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. After completion, the callback function is pushed onto the callback queue. When you call an asynchronous function, the function runs in a separate thread until it completes. 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. Philip then proceeds with an animated explanation of how the call stack works and what happens when we introduce blocking code in our programs. 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. The event loop is not part of the JavaScript runtime language. 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. These functions are part of the WebAPI provided by the browser, which also provides the event loop and the callback queue. Philip starts by explaining that asynchronous functions such as setTimeout and XMLHttpRequest are not part of the JavaScript V8 runtime. The JavaScript runtime, event loop and callback queue Keep reading for my takeaways of Philip's talk, or skip to the end if you want to watch it right away. This is all the more reason to learn fundamental concepts like the JavaScript event loop. In web development, technologies are changing rapidly but the fundamentals remain largely the same. This talk is 7 years old but is as relevant today, as it was back then. I didn't need Stack Overflow to hold my hand anymore and I could fix bugs all by myself. The number of times I reached out to Google for help reduced significantly. I could confidently refactor callbacks to promises and async/await. It was a stepping stone to writing more complex asynchronous code patterns. This talk was the final piece of the puzzle to truly understanding asynchronous code in JavaScript.įrom that point on, I never looked at async code the same way again. 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.Īll the dots started to connect. This fantastic talk finally made the concept click in my head. That is until I watched Philip's talk at JSConf EU. The event loop was an abstract concept and I did not know what was happening behind the scenes. But honestly, there were many moments where I had no idea why my code worked. I could also modify async code written by others without introducing new bugs (most of the time). I was able to write asynchronous code that worked. I also knew not to block the event loop in Node.js otherwise server performance would suffer.Įveryone warned against blocking the event loop! ![]() How exactly it accomplished that though, was a mystery to me. It's using the event loop to handle thousands of concurrent requests. I knew that Node.js is single-threaded but also very fast at the same time. When I first heard about the event loop, the concept kind of made sense. ![]()
0 Comments
Leave a Reply. |