An analogy on JavaScript's single-threaded asynchronicity.

03 Mar 2023
3 min

While I could delve into the technical details of JavaScript's single-threaded asynchronicity, I believe there is already a highly informative and widely shared technical explanation available on the topic. Therefore, I will try to introduce the topic in a more accessible manner that anyone, regardless of technical knowledge, can understand.

The Situation

JavaScript (JS) is a single-threaded language, which means that it operates like an individual doing a job, as opposed to a multi-threaded language which operates like a team doing a job. As a single thread, it cannot work on anything other than the current task.

Despite this limitation, we can achieve asynchronous behavior when working with JavaScript. For example, we can make multiple requests for information simultaneously without having to wait for each one to finish before making the subsequent request.

JavaScript is a single-threaded language. So how is it asynchronous?

The Analogy

This post is targeted at how JavaScript runs in the browser, however, many of these concepts translate to other runtime environments (e.g. Node.js).

To simplify the different elements that take part in the analogy, I will gradually introduce them along the way. As I introduce the elements, I will leave callback blocks as quick references in case you need to refer back to something.

The setup

Let's imagine we have a restaurant with only one waitperson.

restaurant = Website

The waitperson is our interface to ask questions, get answers, and perform actions.

waitperson = main JS thread

The waitperson can only attend to one order at a time. However, getting the client's order does NOT occur sequentially. Instead, everyone’s food goes through the same process of ordering, preparing, and serving at the “same time”. But there is only a single waitperson, so how do they manage it? 🤔

order = JS command

The flow

In this case, the restaurant has more going on than the customers get to see. For example, it needs a kitchen to work. The customer usually does not know what is happening inside the kitchen, yet it handles much of the work required to deliver what they ordered. So, what is the flow here, and, once again, how does one waitperson manage to serve all the orders concurrently?

kitchen = Browser

Let's break it down:

  1. A customer makes an order; during this time, the waitperson is blocked and cannot answer anyone else or do anything else during this time.
  2. Once that is finished, the waitperson either immediately fulfills the request(e.g. the customer asks for a straw) or takes the order to the kitchen.
  3. The kitchen prepares the order using kitchen utensils and tools.
  4. Once the order is done, the kitchen puts it on the counter.
  5. Eventually, when the waitperson is free, the kitchen assistant (who is needed in this case to coordinate between the busy waitperson and kitchen) picks up the order from the counter and gives it to the waitperson.
  6. The waitperson then delivers it to the customers.
kitchen utensils and tools = Web APIs
kitchen assistant = The event loop
counter = The task queue

In conclusion

The beauty of this is that during steps 3 and 4, the waitperson is free and can do other things. So, the waitperson returns to other customers and gets more orders, and the process repeats.

Steps 1, 2, 5, and 6 can ONLY be done sequentially; in other words, the waiter cannot take two tables' orders simultaneously. However, steps 3 and 4 can happen in parallel, the kitchen can and will cook as many orders as possible.

Interestingly enough, the waitperson steps tend to be quick, and the kitchen steps tend to be slow. Still, the kitchen has more than one person working on the orders, so everything works smoothly and seems to happen fully in parallel.

Note that it is critically important that you do not give long tasks to the waitperson; If you do, for example, ask the waitperson to cook, then they will be blocked in cooking while customers are waiting to place their orders. No one answers their calls and rings, making it seem like the restaurant is frozen.

I guess now we know why websites that use JavaScript freeze sometimes. 🤓

I hope this analogy helps you. If it does, please reach out; I'd love to know about it! If it did not, or something is incorrect, let me know; I'm always happy to learn and improve.

Kudos/special thanks to Sean for bringing up the challenge, Angelo for encouraging my analogy to become a blog post, and the foobar Agency team, who supported me along the way with thorough reviews.