The first time I saw the diagram, I skipped the entire tutorial, but after a few months, I started watching it again. The phase and queues in Node JS are now clear to me... thank you so much!
the nexttick has priority over the promise right ? so in the last promise section the next tick should work immediately after the last callback right ?
The nextTick queue takes precedence over the microtask queue, but the example in (5:50 to 8:35) is only half correct. In fact, if someone runs it as an ESM script (.mjs file or with type="module" in package.json), the output will always be: 2 -> 3 -> 1 That's because instead of executing it synchronously, node schedules it as a microtask callback (like wrapping everything in queueMicroTask(() => { ... }), kind of). So after executing the code, the event loop grabs the next callback in the microtask queue until it becomes empty before checking the nextTick queue. Same thing for the 2nd example. Output for ESM would be: promise 1 promise 2 promise 3 nextTick 1 nextTick 2 nextTick 3 nextTick inside Promise nextTick inside nextTick
@@Sarvesh_More I understand the confusion. The closest thing to a reference that you can get is PR 45093 in the official github repo (/nodejs/node/pull/45093), specifically the review made by devsnek. It's an issue of erroneous documentation in the official docs and unfortunately, the PR addressing it has been stale for more than a year now. But basically, the mental model is the exact same, with the initial code being executed in the microtask queue
I am a bit confused. I thought the inner CallBacks would join the next iteration. which would mean the sequence would be NextTick1, NextTick2, NextTick3, PromiseResolve1 PromiseResolve2 PromiseResolve3 NextTick inside NextTick, Promise inside Promise
That's nextTick/Microtask queues' quirk. The event loop will keep executing all the callbacks of each one until both are empty. You can block your program by abusing this mechanism.
promise 1 promise 2 nextTick inside promise promise 3 i thought the order should be like that. because nextTick queue have priority higher than promise queue
Also, I noticed that using Promises puts the execution of the handler to the next cycle. While using regular js callbacks execute right away in for example IO or Timer cycles. Is it fair to say that using callbacks is faster than using Promises? using Promise will add an additional cycle event if it is just Promise.resolve?
Hey, I have a question. Why did you repeatedly use the phrase 'user-written synchronous code' in your explanations? Why do we have to mention 'user written'?
Promise.resolve().then(() => console.log('start resolved promise')); process.nextTick(() => console.log('start nextTick')); I have run this in my local but bit confusing for me. I am getting [nodemon] restarting due to changes... [nodemon] starting `node justDemo.js` start resolved promise start nextTick [nodemon] clean exit - waiting for changes before restart As you can see I got in same order, not able to understand.
The answer is rather complicated and is related to how operating systems handle each type of task, but in essence, each queue is made for some kind of work that has its own quirks. For example, timers are organized in an ordered heap that puts expired timers in the timers queue, while close functions are low priority and only need to be pushed as they come (FIFO).
The first time I saw the diagram, I skipped the entire tutorial, but after a few months, I started watching it again. The phase and queues in Node JS are now clear to me... thank you so much!
Don't know what you have to apologize for. The switches between the diagram and the code are fantastic and help more. Thank you
the nexttick has priority over the promise right ? so in the last promise section the next tick should work immediately after the last callback right ?
Your teaching style is so so beautiful that I was able to predict the result. Thank you so much :)
Core concepts explained with a heart winning simplicity.
You are one of the best teachers I ever met, sir. Everything explained well and short to the point. Got it in one go and I got my confidence boosted!
Your explanation is the clearest one I've ever heard. Thanks a lot!
Thanks for a crystal clear explanation. i have watched react series too and i learnt a lot as mostly focuses on practical part.
I magically got it right on the first try thanks to your great explanations.
Too deep knowledge, that's also for free... thanks man
The nextTick queue takes precedence over the microtask queue, but the example in (5:50 to 8:35) is only half correct. In fact, if someone runs it as an ESM script (.mjs file or with type="module" in package.json), the output will always be:
2 -> 3 -> 1
That's because instead of executing it synchronously, node schedules it as a microtask callback (like wrapping everything in queueMicroTask(() => { ... }), kind of). So after executing the code, the event loop grabs the next callback in the microtask queue until it becomes empty before checking the nextTick queue.
Same thing for the 2nd example. Output for ESM would be:
promise 1
promise 2
promise 3
nextTick 1
nextTick 2
nextTick 3
nextTick inside Promise
nextTick inside nextTick
hey i would really appreciate if you could provide me some reference where i can study about it. This behavior looks confusing.
@@Sarvesh_More I understand the confusion.
The closest thing to a reference that you can get is PR 45093 in the official github repo (/nodejs/node/pull/45093), specifically the review made by devsnek.
It's an issue of erroneous documentation in the official docs and unfortunately, the PR addressing it has been stale for more than a year now. But basically, the mental model is the exact same, with the initial code being executed in the microtask queue
@@privateanon7623 Thank you.
Your teaching style is so so awesome. I'm able to predict the result. Thank you :)😀
11:57 I thought the nested nextTick ("nextTick inside nextTick") will be executed in the next event loop iteration.
Simply outstanding🔥. U made it easy to catch those complex concepts 🎉
Sir! You are great in this field!
Hi, your explanation is the clearest one I've ever heard. Thank you very much, but can I ask you for this slide for reference?
beautifully explained
your explanation is soooooo good that I got it right
Thank you so much for this tutorial. It helped me a lot
Really great explanation and on point with visual representation 👍
It's been wonderful sir, and i got it right in the first try and you made it possible for me to guess
I always give your video a like before even watching it.
According to my understanding, the global function will also be removed from the call stack before running any async code
no
Greate explanation with patience👌👌
Awesome , nailed iT 🔥
Thanks a lot. You have made my day!
amazing
I am a bit confused. I thought the inner CallBacks would join the next iteration. which would mean the sequence would be
NextTick1,
NextTick2,
NextTick3,
PromiseResolve1
PromiseResolve2
PromiseResolve3
NextTick inside NextTick,
Promise inside Promise
That's nextTick/Microtask queues' quirk. The event loop will keep executing all the callbacks of each one until both are empty. You can block your program by abusing this mechanism.
Thanks a lot, Vishwas
But the nexttick has priority over the promise ,right . So nexttick should be executed in the promise section before the last promise callback ?
Just wow concept 🙏🥰
great job! thank you
Well explanation
promise 1
promise 2
nextTick inside promise
promise 3
i thought the order should be like that. because nextTick queue have priority higher than promise queue
How does call stack knows to which queue it should put callbacks to ???
I thought after promise 2, nextTick inside Promise will execute as nextTick Queue is having hgher priority
Also, I noticed that using Promises puts the execution of the handler to the next cycle. While using regular js callbacks execute right away in for example IO or Timer cycles. Is it fair to say that using callbacks is faster than using Promises? using Promise will add an additional cycle event if it is just Promise.resolve?
Yes callbacks are a little bit faster but the difference is negligible specially when you consider the elegance and readability promises provide.
Hello sir.. i got the promise.resolve.then consoled first before the process.nexttick console
Yes i got the same results
Got right for next tick, but little different for promise.resolve,
So Calling nextTick inside nextTick actually executes the callback in the same cycle and not in the next.
It goes beyond that. NextTick and Microtask queues are emptied after every event loop action, rather than phase or iteration.
Got right man!
thanks teacher 43
Awesome Video...
*space bar* 4:06 ~ "That's what she said". *space bar*
i got that right
Hey, I have a question. Why did you repeatedly use the phrase 'user-written synchronous code' in your explanations? Why do we have to mention 'user written'?
Promise.resolve().then(() => console.log('start resolved promise'));
process.nextTick(() => console.log('start nextTick'));
I have run this in my local but bit confusing for me. I am getting
[nodemon] restarting due to changes...
[nodemon] starting `node justDemo.js`
start resolved promise
start nextTick
[nodemon] clean exit - waiting for changes before restart
As you can see I got in same order, not able to understand.
Got it right
In my case promise queue running before process.nextTick queue
Why did they make it so complex? Why do we need so many queues?
The answer is rather complicated and is related to how operating systems handle each type of task, but in essence, each queue is made for some kind of work that has its own quirks.
For example, timers are organized in an ordered heap that puts expired timers in the timers queue, while close functions are low priority and only need to be pushed as they come (FIFO).
🙏👍👍
sir where is your feet i want touch it for it's clear explaination.............thanks sir.........always respect for great teacher.......
{2024-01-30}
စောက်ပေါ 🤗👍👏👏
Good tutorial but, god, your ending of all senteces is so annoying
Promise.resolve().then(() => console.log("this is Promise 1"));
process.nextTick(() => console.log("nextTick 1"));
Why output is actually coming :
this is Promise 1
nextTick 1
same