Therefore, I will try to introduce the topic in a more accessible manner that anyone, regardless of technical knowledge, can understand.
many of these concepts translate to other runtime environments (e.g.
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.
Let’s imagine we have a 🛖 restaurant with only one 🧵waitperson.
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
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:
- A customer makes an 📝order; during this time, the 🧵waitperson is blocked and cannot answer anyone else or do anything else during this time.
- 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.
- The ⚙️kitchen prepares the 📝order using 🔪kitchen utensils and tools.
- Once the 📝order is done, ⚙t️he kitchen puts it on the 🛎️counter.
- 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.
- The 🧵waitperson then delivers it to the customers.
- 🔪 kitchen utensils and tools = Web APIs
- 🧑🍳 kitchen assistant = The event loop
- 🛎️ counter = The task queue
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 hope this analogy helps you. If it does, please reach out. We want to know about it! If it did not, or something is incorrect, let us know; we are always happy to learn and improve.
Kudos/special thanks to Sean for bringing up the challenge, for encouraging my analogy to become a blog post, and the foobar Agency team, who supported me along the way with guidance and thorough reviews.