Understanding the JavaScript event loop

AaronSunday, March 13th 2016

For many people the event loop in JavaScript is something of a mystery, to understand the event loop first we need to understand why JavaScript has an event loop in the first place.

Why JavaScript has an event loop

JavaScript is single threaded but what differentiates it from other single threaded languages is that while your code always runs in a single thread, I/O operations are run in other threads and then they fire an event for your code to action the result. So while the I/O operation is in progress your code can do something else, this actually makes JavaScript a very efficient language.

The event loop

So now we know why JavaScript has an event loop lets go over exactly what the event loop is. One of the best ways to think of the event loop is imagine you have an island and on that island you have a minion who will do whatever you ask him to. However, this minion can only do one thing at once, so you build a terminal on the island and enter into it a list of things for your minion to do. Whenever your minion has nothing to do he goes to the terminal, presses a button and it prints out one task from the list. Your minion then reads that task and goes off to complete it.

So let's say you gave your minion this list of tasks:

  • take out the rubbish
  • get the shopping
  • clean the house
  • mow the lawn

The first thing your minion does is go to the terminal and press the button to print off the first task - to take out the rubbish. Your minion reads the task and then proceeds to go and get the rubbish and take it down to the dock where it'll get picked up later by a rubbish boat.

Once he's done this he has nothing to do so he goes back to the terminal, presses the button and gets another task - to get the shopping. He reads the new task, goes into the house and compiles a list of required shopping. He then takes it down to the dock and puts the list into a box where it'll be picked up and later on the shopping will be delivered to the dock. At this point, once the list is delivered to the box, your minion has nothing to do.

So, he goes back to the terminal and prints another task. This time he needs to clean the house, easy enough, he goes off and cleans the house. Once he's done he comes back to the terminal and prints another task. While he was cleaning the house the shopping was delivered to the dock and a new task was added to the list - to collect the shopping and unpack it. But when he prints the next task it says to mow the lawn, in this case there's an automatic lawn mower. So he goes and sets the lawn mower going. Then, as he has nothing to do, goes back to the terminal and presses the button.

The task is to get the shopping so he heads down to the dock to collect the shopping and unpack it. While he's doing this the lawn mower finishes and needs to be put away. This creates a new task on the terminal - to put the lawn mower away. When your minion goes back to the terminal he picks up the task to put the lawn mower away, which, he does.

In this analogy the terminal is the event loop, your minion is the main thread and the lawnmower or shopper at the dock are asynchronous I/O operations. So you could replace the shopper with a http request and the lawnmower with disk I/O.

This makes the JavaScript model one of the most efficient models for high throuput processing as anything blocking is handled in a different thread automatically for you. This means that the only thing that will slow your program down is your code which is the one downside. JavaScript is not normally suited to computationally intensive work as it would block the event loop, fortunately that's what web workers are for.