Callback Queue VS Microtask Queue
Vložit
- čas přidán 17. 11. 2020
- In this lecture, you will learn what is Callback queue and Microtask Queue and which one takes the priority over another.
A callback function can wait for its execution in any one of the queue i.e. callback queue or microtask queue and once the call stack is empty, event loop pushes the callback functions from these queues to call stack for there execution.
Microtask queue takes priority over the callback queue and callback functions of Microtask queue are executed first. Once all the functions of callback queue are executed completely, then only callback functions of callback queue gets executed.
I dont know... im so happy with the javascript topics you are explaining.. subscribed
Ps: i havent even watched one video yet..
Beautiful explanation, probably the clearest and best precise explanation I've seen. Well done!
Glad it was helpful!
Thanks for explaining microtask queue and its purpose for existence in browser so well.
Thanks!
Very nice. Thank you
Amazing video bro. I was searching for this kind of lecture from the last 2 years.
Glad you liked it :)
Thank you very much dear for this simple explanation ☺
Beautiful explanation
Great video, thank you for your explanation!
Wow such a quality content, keep doing your awesome work man
Thank you for this video, your diagrams helped a lot!!
Glad it helped! :)
very Useful
really good explanation !
my english is nicht gut, but it still so easy to understand what u explain! THANKS!
Glad to hear that!
very helpful video but one more question what difference Callback Queue VS Microtask Queue
Nice !
I have a question, since I've seen conflicting information pop up in every article I read.
When you talk about Global Execution Context (the *(anonymous)* function in V8 that always appears first on the Call Stack), that is our .js file that first executes, in order to create the "environment" for the code in that file. That part I understand.
However, when you talk about the empty stack, doesn't that also mean that the *(anonymous)* function needs to be taken off the stack as well? Wouldn't that mean that the JS engine has reached the end of the file AND THEN started to check for the Microtask and Callback Queue in order to finish the waiting tasks?
The part that's confusing to me is that your slides show the Global Execution Context still existing on the stack as the only function and therefore, the stack is considered "empty". While in some other explanations, I've seen even the *(anonymous)* function being popped off the stack AND THEN the stack is considered empty to start running the callbacks from both queues (priority first).
What would be the correct explanation in this case?
The Call Stack is empty when: the GEC is popped off (end of file) OR GEC is the only thing that remains (file is still running)?
That's a very good question and I have covered this part already in one of the lectures.
The global execution context is created as soon as the program starts executing. And it is popped off the call stack only when the program is stopped.
If there is no code to execute in global scope, then also GEC will stay there in call stack. It will only pop off when the program has finished executing all code including callback functions.
@@procademy Oh, I see.
So our script isn't done executing AS LONG as there is still code to be run.
Which means that if JS engine has reached the end of the file its running BUT if there are callbacks in the Callback and Microtask Queue waiting to be executed, then our GEC (our *anonymous* function [the entire file]) STILL cannot be removed from the stack. It needs to wait all for all callbacks to return to the stack in FIFO order (microtasks first then callback queue) to finish and when these two queues are emptied, then it can end execution of the file and pop off the stack.
But this is that confusing part I was talking about.
If the GEC isn't yet popped off the stack (the only item on the stack) as the JS engine has reached the end of the file AND there are callbacks in both queues waiting to be executed, wouldn't that mean that technically, call stack isn't empty? Or is the "empty stack" statement only used to describe it when every other stack frame is popped off the stack, THAT ISN'T Global Execution Context?
On the side note, your videos are amazing.
I know a fair amount of JS but the "behind the scenes" of it are still confusing to me. These videos definitely help in understanding how everything works, which will then help me write and understand code when I use different browser APIs for asynchronous code. You might see a few more of my comments about further questions on related topics 😊
Have you also made video on Async - Await ?
can you make a video how async and await works in execution context
Is it possible to print "SetTime callback executed" before "Resolved promise data!"? as it takes more time to execute.
Please share this channel with others if you like my videos...🤝🤝
hi, I have a question, is this event loop the same for Node.js?
The Nodejs event loop is implemented differently than the browser based event loop.
While Nodejs uses the Google's V8 engine as it's runtime, it does not use V8 to implement the event loop.
Please share this channel with others if you like my videos...🤝🤝
Is there any difference in the node.js event loop compared to the browser event loop? What are the nodejs API functions
Both are quite different. Browser's event loop doesn't depends on I/O Operations. But Node js event loop depends on I/O operations. Here the Node js event loop main goal is to separate out the main process and try to execute I/O operations and other timer API's asynchronously.
Its out of scope to talk about node js event loop here. But i will cover it in node JS course and there i will also cover Node JS APIs :)
@@procademy ok. thank you
who pushes global execution context to call stack ??is it JS Engine?
That's right. When the program is compiled and start executing, JavaScript engine creates a global execution context in the call stack where all top level codes get stored and executed.
Please watch my playlist "How JavaScript works behind the scenes" to understand it better.
Please share this channel with others if you like my videos...🤝🤝
What if u warp a setTime function inside a promise ?
Please share this channel with others if you like my videos...🤝🤝
const promise1 = new Promise((resolve, reject) => {
console.log(1)
resolve('resolve1')
})
const promise2 = promise1.then(res => {
console.log(res)
})
console.log('promise1:', promise1);
console.log('promise2:', promise2);
o/p
1
"promise1:", [object Promise] { ... }
"promise2:", [object Promise] { ... }
"resolve1"
So my question is my why console.log(1) print first?
That's because, the handler function of promise1 will be executed and first it will log 1 then it will return the promised data from there.
Hope it make sense.
The explanation is not correct.