Written by Kirill Bychkov for UppLabs.
I think it's not difficult to guess what sequence these logs will be called in. Let's check.
But let's take a look at what's going on under the hood. In the example, I am using this helpful site
When the program starts, it runs through the lines of code. When an asynchronous operation comes across, the interpreter throws this operation into a Call Stack. In the stack, it begins to look like a certain set timeout and as a browser API. Then it throws out the set timeout and registers some anonymous function in the web APIs, which will be executed when the browser completes the set timeout after 5000 seconds. Next, the anonymous function enters the callback queue. An endless loop runs in the queue, which runs over its elements, and if it detects that the function is ready, it throws it back into the call stack and executes.
Thus, we do not block the work of the code. We are talking not only about set timeouts but also about other asynchronous operations, such as event listeners that work along with the server.
But what happens if 0 is passed as the second parameter to the timeout set? Exactly the same. Let's see.
The browser will still drop the function into the web API, and the program will continue to work.
Let's also take a look at how the event listener works.
The event listener, as mentioned above, is also an asynchronous event and goes to the web API. You now understand the importance of unsubscribing from listening to events. You can read more details here
Let's take the same event example and try to click the button a few times.
We see a queue of events. This is the macro task callback queue, a v8 term. Tasks from the queue are executed according to the first-in-first-out rule.
- Rendering of the page never happens during the execution of a task by the engine. It doesn't matter how long the task takes. Changes to the DOM are rendered only after the task is completed.
- If the task takes a very long time and the browser cannot perform other tasks or process user events. So, sometime later the browser offers you to "kill" the long-running task. This is possible when the script contains a lot of complex calculations or an error leading to an infinite loop.
We could see the micro tasks in the last example. When the macro task is executing, the functions from it are placed in the call stack. The new macro task does not start its execution until the micro tasks have finished there. If you need more examples, you can check here.
Depending on the specifics of the task, it may turn out that you will be using async/await, callbacks, or some mixture of different technologies. In fact, the answer to the question which asynchronous development methodology to choose depends on the specifics of the project. If a certain approach allows you to solve a problem using readable code that is easy to maintain and other team members can easily understand, then this approach is what you need!
Now you can use callback, promises or async / await with understanding how it works in the browser :)
I hope this article was helpful for you. You can also find more useful information on our blog.