Hm no, not really. Imagine we have 4 tasks, and the 2nd tasks needs a delay. If this delay would've happened on the main thread, nothing would've been able to run on the thread while we were waiting:
However, the web api gives us some sort of asynchronous behavior by letting us put stuff "to the side" so to say. We can now keep on running other tasks, thus keeping an interactive UI, while tasks are running in the background:
Hope this somehow made sense haha I just woke up so my illustrations may not be optimal 😜
So it's safe to say the purpose of the event loop is to prevent any callback clashes? 🤔
Hm no, not really. Imagine we have 4 tasks, and the 2nd tasks needs a delay. If this delay would've happened on the main thread, nothing would've been able to run on the thread while we were waiting:
However, the web api gives us some sort of asynchronous behavior by letting us put stuff "to the side" so to say. We can now keep on running other tasks, thus keeping an interactive UI, while tasks are running in the background:
Hope this somehow made sense haha I just woke up so my illustrations may not be optimal 😜
Great!
So can we say that preventing callback clashes is the queue's job, instead of event loop's one?