Javascript Foundation: Javascript RunTime
Synchronous and Asynchronous code
With single-threaded synchronous code that Javascript runs, it's going to be hard to execute long-running tasks. This means that if we have a function on our website that takes perhaps 5 seconds to load, we won't be able to do anything else on the website until its done loading.
And that is not good!
But the good news is that most of the time, you are never just using the Javascript engine alone — which is synchronous.
And this is where the idea of asynchronous code comes in. In this case, it's not just the Javascript engine running our code, we have something called the Javascript runtime.
We have mentioned before that Javascript is a single-threaded language — it has only one stack and one heap. Hence if any other program wants to execute something, it has to wait until the other program or function has finished executing.
The Javascript runtime ensures that the web browser is working in the background, while the synchronous Javascript code is running. It uses the Web API to communicate and let the Javascript engine know when its back with some data — work that it has had been doing in the background.
The web API comes with the browser(Chrome, Microsoft, Edge, Firefox, Safari). All of them have their Javascript engine implementation and all of them have a Javascript runtime that provides a web API.
Web APIs are applications that can do a variety of things, for example, send Http requests, listen to dom events, delay execution using something like set timeout, caching or database storage on the browser.
Browsers underneath it all use low-level programming languages like C++ to perform these operations in the background.
They are called web APIs because they are APIs provided by the browser; we say they are asynchronous because you can instruct these APIs to do something in the background and return data once they have finished. Meanwhile, we can just continue working on our Javascript call stack and execute functions.
Let's go a little deeper
Normally, we have items in the call stack to execute but as soon as an item comes up that's not Javascript and its part of the web API, the call stack will send it to the web API and the web API will perform these executions in the background.
For example, with setTimeout(), you usually want something to happen afterward, so once the web API is done working on it — may be finished fetching some data from a server, it's going to send this data to a callback as seen d1.1.
The event loop will keep checking to see whether the call stack is empty. If the stack is empty, it's going to push the callback onto the stack.
Notice the order 1, 3, 2.
- We added console.log(‘1’) to the call stack and removed it.
- We added setTimeout() to the stack and the Javascript recognized it as a part of web API and so it sends it over to the web API.
3. It continues to run the code — adds console.log(‘3’) to the stack.
Now behind the scenes, the web API takes the setTimeout() and starts a timer that is going to run for 1 second. Once it's over, it will notify us with a call back which is console.log(2) in this case.
This console.log(2) goes to the callback queue, and it will wait there until the event loop confirms that the call stack is empty.
It's important to know that the event loop only runs after the whole Javascript file has been read. In our case console.log(3), no matter how fast the web API responds with a callback, the event loop won't start putting anything into the call stack until it's finished running or it has run through the entire file at least once.
a callback, the event loop won’t start putting anything into the call stack until it’s finished running or it has run through the entire file at least once.
After console.log(3) is printed and popped off the call stack, console.log(2) will be added and run hence the results above: 1,3,2.
Look at the process here
Now, this process will also happen even if the setTimeout() was 0. Because no matter how fast this setTimeout happens, it's still sent to the web API, still gets sent to the callback queue, and the event loop still needs to check to see whether the call back is empty.
And this is how we have the power of asynchronous code. Instead of being limited to one call stack and one memory heap, whenever we get tasks that can be asynchronous — tasks that take a long time like modifying the DOM or making Http requests, in that case, we just send those off to the browser so it can execute in the background. And it will use the callback queue and event loop to notify us when the work is done.
