Today I had interview and was asked about execution context and i explained him based on this video. my interviewer was so impressed with the my answer. he said "This is the best explanation i have heard so far". made my day 🙂
13:45 "The event loop job is to look at the stack and look at the task queue. If the stack is empty, it takes the first thing on the queue and pushed it on to the stack."
@@mementomori8856 it's async for you as a developer, but at the end, there has to be a queue for that poor single thread... serverless is serverless for you but at the end there has to be a server to run your code!
@@viridianite It does make sense, but only if you have some basic working knowledge or better on how multithreading works, and the fact that JS is still a single-threaded language despite supporting asynchronous code.
00:53 how does javascript actually work ? 02:46 V8, setTimeout 04:03 the call tack 07:18 blocking, what happens when things are slow 10:35 aynchronous callbacks, setTimout 11:13 aynchronous callbacks, the call stack 11:56 concurrency 12:50 stack, webapis, eventloop, task queue, console
00:53 how does javascript actually work ? 02:46 V8, setTimeout 04:03 the call stack 07:18 blocking, what happens when things are slow 10:35 aynchronous callbacks, setTimout 11:13 aynchronous callbacks, the call stack 11:56 concurrency 12:50 stack, webapis, eventloop, task queue, console
@@xxicenturyfuck1195 He mentions he used Keynote, which is the powerpoint for Apple software. There a ton of tutorials online showing how to do animations
Funny how many "senior" JS devs think that they are clever AF because they interview you with this kind of questions but, in here, he managed to explain so clearly these concepts that destroy all the "mystery" of these guys intelligence ... What an awesome explanation! Simple and sharp!
I've returned to this video several times to engrain the concept of the event loop in my head. It's so clearly explained and so useful. Thanks so much for making it!
Genius talk, seriously. Not hiding behind many fancy technicalities and being able to still convey high-level concepts and make them understandable is surely not an easy skill. Props!
It's the first time I'm giving a comment in 7 years. This guy did such a great presentation. It was fantastic. Such a complex topic broken down into small lucid chunks ! Great work.
This is one of the best lectures on JavaScript that I've seen anywhere. Phillip does a great job of using visualization to explain some of the more complicated aspects of JavaScript programming while making it look easy. That's truly commendable.
I've been watching some interviews and mocks preparing for my own, and people nebulously reference 'the event loop' and single-threadedness very often, like "How does X work?" "ahh, the event loop", but more in a buzzword way than as an explanation, so thank you for this video. It was super helpful
From someone who does not have a degree in computer science, I have to say, this is one hell of a good explanation! I only which that the teachers that I had during my CS degree, explained things as good as this guy. Really awesome!
7 years later some things have changed. Now we have service workers in a seperate thread. And we have await/async functions. But yes, this talk makes the things clearer to understand. thank you!
Really, Amazing talk, bro! :) Once I came up across a scenario where calling a function, say "func()" did not work rather, setTimeout(func, 0) worked! Now, I understood the reason completely!! :)
I just pause while watching to recheck the speaker's name, wondering that we still have such great speakers. This is by far the best tech conference talk I ever watched in my life!!
This video is life-changing! Thank you for this, Philip! It takes great understanding to explain complex things in simple ways. And thank you for not gatekeeping - we need more people to come into tech and videos like this make sure that even noobs understand and can work with seemingly hard concepts!
The intro music tho.... I turned off the lights and got my glowstick game on. He's amazing. It was an excellent video. My ADHD did not kicked in ever while watching it. 10/10. Will buy again.
One of the best videos on event loop I've seen. The examples, animations of queue and stack are very clear and I've got almost everything, although I'm just starting to learn async functions in JavaScript Thank you for this great explanation!
8 years down the lane for this video, current in year 2023. Buffering through many videos on event loop still find this one the best. The energy of this man...can feel it on screen as well. Wish i could attend his session once in my life in person.
@19:18 you can see his history. I found it reassuring that a guy with this level of knowledge still has to look up the syntax for Date(). :-) Great dissection of the event loop.
Good example of why code interviews that just test how well someone has memorized various language apis/functions are an ineffective way to determine the candidate's knowledge :)
@@timeslowingdown None of those tests actually check if you have those things memorized. All those tests are there to see how you look for the best available solution
@@lighterinthestorm Finding the solution to a single function with input and output is very different than writing an entire application or maintaining it, so I beg to differ
Remembering the correct parameters for a function in a library is not a prerequisite for being a good developer, in the same way that needing a calculator in a math exam doesn't mean you're cheating. If you like calculating or memorising sure go ahead, but if you're lazy it's fine
I find myself coming back to this talk as i progress in my career as a JS developer. I think this is my third time watching it, it gets better every time. Well done.
I have been trying very hard understanding this whole JavaScript event-loop, callback, and asynchronous concepts for WEEKS (and failed), despite tons of google searches, article readings and tutorials. I think I finally "got it" after watching this video. So thank you SO MUCH for the talk Philip!!! (and thanks for sharing this JSConf!). I sense "hope"... in understanding and using JavaScripts :)
Great explanation! Just one note: at 23:35 , lines 12 and 13, I think it should instead be array.forEach(function (i) { setTimeout(cb, 0, i); or else the array element will not be passed to the callback and console.log() will log them as 'undefined'.
Just came from Theo t3. I’m a web dev fresh out of college with about 5 months full time experience. This was awesome. Still teaching us almost 10 years later!!
0:58 - How does JS even work? 2:43 - JavaScript Runtime 3:39 - Bigger Picture 4:06 - The call stack 6:54 - blowing the stack 7:24 - blocking: What happens when things are slow? 8:58 - Why is this a problem? because, browsers. 10:25 - the solution? asynchronous callbacks 11:49 - Concurrency & the Event Loop 12:25 - browsers are MORE than just the runtime 12:56 - demo with async code (web API) 14:55 - setTimeout with 0 timeout 16:15 - XHR Web API (AJAX request) 18:15 - loop demo 19:57 - setTimeout & minimum time to execution 20:22 - callbacks 22:41 - Render Queue 24:50 - scroll handlers
Interesting how no textbooks mention this stuff wich in my opinion is crucial in understanding core javascript and especially closures (especially when every example on closures out there contains *for* loop with setTimeout and never explains or even mentions event loop and why does *for* loop first finish its iterations and then invokes setTimeout callbacks)
What he means is that a very common practice question given to novices to see if they understand closures is the following: const arr = [0,1,2,3]; for (var i = 0; i < arr.length; i++) { setTimeout(function() { console.log('index ' + i + ', value: ' + arr[i]); }, 3000); } //Prints 'index 4, value: undefined' The issue here is that because var is function scoped and not block scoped, i will break out of the loop when it hits the value 4 (as i will now equal arr.length, breaking the test of the for loop). As index 4 is out-of-bounds, it returns undefined as the value for arr[4]. Closures via something like the let keyword mitigate this problem, however. So the test in question is to see whether or not the novice understands the issues of closure with var versus the new block-level variable definers: let and const.
Javascript: The Good Parts by Doug Crockford explains closures very well. Also function-orientation. Other core JS lang features, but not the event loop.
@@johnb1391 Or maybe a less granular way to explain it is: once the for loop is done setting up the setTimeout callbacks, it is finished, and the variable is at its final value of 4. Meanwhile the callbacks run for 3 seconds each, and they are still active - when they print the value of i, it is always 4 (unexpected). You can create closures around the timeout function value to keep the value of i as it was when the callback was created, by either passing it to a function outside of the loop to create the callback, or just making that setTimeout function an IIFE - immediately invoking it creates the closure while the i is still at its iterative value. Well I guess that was more words lol. Is there any simple way to explain closures?
@@stormwarrow thanks that's a great explanation,, can you include some code examples for "You can create closures around the timeout function value to keep the value of i as it was when the callback was created, by either passing it to a function outside of the loop to create the callback, or just making that setTimeout function an IIFE "?
I wouldn't be able to say how much of a help this explanation has been to my JavaScript understanding. Of course, I know now that might be 'cause the callback in charge to say such thing is waiting for the stack pile to be empty.
Talk about boss mode, great work by Philip! The loop tool he created is amazing for helping to visualize the runtime, event queue/loop and web api! I can only imagine the time that went into creating and researching how to build it and you can see by his facial expression how much of a challenge it must have been hahah!
I remember I watched it back in 2016, and now in 2022, I came back to check if it was as good as I remember, and... yes, it's definitively is. There's a real good stuff here, congrats Philip!
I randomly watched this video a week or two before I went on a job interview five years ago. The event loop came up in some advanced JS discussion and I'm convinced it's a big part of why I got the job. Got another interview coming up and I figured I should probably revisit this just to make sure I still remember it. Still just as informative as I recall.
Its not just the content of the video that is amazing but also the slides are done so nicely and as a speaker i know making a simpler presentation on a technical topic is very hard. Kudos Philip!
The timeout is executed in the WebAPI right? What does that means? WebAPI executes in another thread? or why the code running in the Web API (section?) does not block the unique Thread JS has or does JS have other threads in the background?
+Bernardo Leon Yup there is a dedicated thread for the event loop and a bunch of threads in a thread pool to handle the callbacks. The thread pool is transparent and is not meant to be accessible from any JS constructs. However as of lately we have Web Worker thread pool progammatically accessible to JS to offload long running CPU and I/O intensive work to a different background thread pool.
Trying to answer all your questions The timeout is executed in the WebAPI right? - Correct What does that means? - It means the *timeout* code is running as part of a different part of the Browser process (Chrome, Firefox). It is *NOT* running within the Javascript section WebAPI executes in another thread? - It runs in a different area of the browser process and it able to run concurrently with the code that is running on the Javascript side or why the code running in the Web API (section?) does not block the unique Thread JS has or does JS have other threads in the background? - The browser is able to run multiple things (the WebAPI, the event loop, the rendering engine and the Javascript processor to list a few) concurrent. But the JS processor does *NOT* have other threads in the background, in its limited view it can only do one thing at a time which is defined as what's one the top of the call stack
@@TheBohrabohrafamily Thanks, I was suspecting that the "it runs in another thread" explanation was incorrect. n.b: The distinction between concurrency and parallelism is an important one.
I'm watching this in 2021. I overlooked this video because it's old. Well I came back because I was disappointed with all the other more recent videos I watched. The speaker here did an excellent job at simplifying the topic. I'm so glad I watched this. I just hope it is still very relevant today. I can't imagine much has changed.
Still watching this in 2020 and has made JS clearly than anything, and the joke at ~ 17:30 was great to see. Shows personality and gives an almost Steve Jobs feel. Top draw.
So no one bothered to ask if JS is single-threaded, how can it also, in parallel, maintain an event-loop. The event-loop is actually provided by the browser.
hi from student in Yandex-Praktikum web development courses in Russia. For me as a beginner to understand how js works, this video was very informative. so thanks for him and all the best
Honestly, I watched it last night while sleeping but the way my guy explained was so good that I am still thinking about the diagrams he showed this morning!
I have one doubt - If task queue waits for whole call stack to gets cleared up, then all async callbacks should execute after the whole program is finished. Since the main() is at the lowest level in the call stack? So if we run something in react like setState, it should be executed in the end, which doesn't happen. What am I missing here?
This talk is the perfect example of "If you can't explain it simply, you don't understand it well enough". Well done Philip.
That's quit simple!
agreed
Agreed!
CS50 teacher explains very well too.. Sometimes i'm worried he will forget to breath..
That sounds wonderful.
9 years later, and this is still pure gold.
yeah, but now there are microTask queue too, which one is prioritized and execute the callbacks before task queue
@@vitvitvitvitvitvitvitvit we also have WebWorker(s) too
@@vitvitvitvitvitvitvitvit you got answer to this??
yes i agree
10 years from my time!
He understood it in 18 months, for me it took 26 minutes, that is how much he helped me, really appreciate it. Time is all you have. Thank you man!!!
Not nearly at the same level though
Today I had interview and was asked about execution context and i explained him based on this video. my interviewer was so impressed with the my answer. he said "This is the best explanation i have heard so far". made my day 🙂
amazing
nice!
Did you get the job though?
Nice !
congratulations
8 years ago and this is still my favorite explanation of the event loop. Brilliant communication.
i can't even express how much i appreciate this video. i watch it every couple of months as a refresher. and encourage my team to do the same.
13:45
"The event loop job is to look at the stack and look at the task queue. If the stack is empty, it takes the first thing on the queue and pushed it on to the stack."
what if there's multiple tasks in the queue ... and they'll get done in some order ... doesn't that make it a sync-function of it's world??
never mind ...
@@mementomori8856 it's async for you as a developer, but at the end, there has to be a queue for that poor single thread... serverless is serverless for you but at the end there has to be a server to run your code!
@@khaledelnagar4135 This makes no sense
@@viridianite It does make sense, but only if you have some basic working knowledge or better on how multithreading works, and the fact that JS is still a single-threaded language despite supporting asynchronous code.
"I did not do a computer science degree, so these words... they're words"
I relate so so deeply with that
watching this in 2019, and it is still the best source to learn JS event loop.
couldn't agree more, just rewatched it there for a refresh
watching this in 2020
@@castelocl and still relevant!
still the best in 2020
@@360-sreet-view I agree
00:53 how does javascript actually work ? 02:46 V8, setTimeout 04:03 the call tack 07:18 blocking, what happens when things are slow 10:35 aynchronous callbacks, setTimout 11:13 aynchronous callbacks, the call stack 11:56 concurrency 12:50 stack, webapis, eventloop, task queue, console
00:53 how does javascript actually work ?
02:46 V8, setTimeout
04:03 the call stack
07:18 blocking, what happens when things are slow
10:35 aynchronous callbacks, setTimout
11:13 aynchronous callbacks, the call stack
11:56 concurrency
12:50 stack, webapis, eventloop, task queue, console
I like this guy. He's so humble and explains things with such clarity - an for a universal audience. That's no easy feat.
John totally agree, great presentation
+John Yeah! I just saw he's from &yet, they seem like a really thoughtful bunch
This was hardly for an universal audience
@@bvrulez why man?
"Fucking Gilfoyle"
This gave me a breakthrough moment in realizing how async JS actually works. Really good talk.
Graduated in 2015, worked in JS alone for 4+ years, discovered this only today! Thank you
This guy just cleared the stack for my callback queue of understanding javascript to execute.
Great explanation.
@@xxicenturyfuck1195 He mentions he used Keynote, which is the powerpoint for Apple software. There a ton of tutorials online showing how to do animations
Funny how many "senior" JS devs think that they are clever AF because they interview you with this kind of questions but, in here, he managed to explain so clearly these concepts that destroy all the "mystery" of these guys intelligence ...
What an awesome explanation! Simple and sharp!
I've returned to this video several times to engrain the concept of the event loop in my head. It's so clearly explained and so useful. Thanks so much for making it!
You know this is the best video when content creators link this video and call it as the "best explanation for event loops".
Genius talk, seriously. Not hiding behind many fancy technicalities and being able to still convey high-level concepts and make them understandable is surely not an easy skill. Props!
Came here from the Odin Project. This video is gold
It's the first time I'm giving a comment in 7 years. This guy did such a great presentation. It was fantastic. Such a complex topic broken down into small lucid chunks ! Great work.
Puh, hey I'm your callback. Why did you queue me with 5 years delay?
This is by far one of the best presentations on any programming concept I've ever seen. Absolutely brilliant. Thank you!!
This is one of the best lectures on JavaScript that I've seen anywhere. Phillip does a great job of using visualization to explain some of the more complicated aspects of JavaScript programming while making it look easy. That's truly commendable.
this video changed my life,.. great
+Nadiar AS Same, his show is really clear, I learned so much thanks to him :p
Yeah, awesome presentation
Truly is. Mine too. Simply Brilliant Video
You need to know about Tony Alecia
lol.
I've been watching some interviews and mocks preparing for my own, and people nebulously reference 'the event loop' and single-threadedness very often, like "How does X work?" "ahh, the event loop", but more in a buzzword way than as an explanation, so thank you for this video. It was super helpful
Best event-loop explanation ever .... !!!
What about Jake Archibalds explanation?
@johannbauer2863 yeah, that one helped me to learn about the missing Microtasks queue of Promises/Await since they came later in ES!!
This is a fantastic talk and explains things clearly.
10 years of JavaScript / TypeScript development and am only learning how it truly works now.
From someone who does not have a degree in computer science, I have to say, this is one hell of a good explanation!
I only which that the teachers that I had during my CS degree, explained things as good as this guy.
Really awesome!
wish
wish
wish
7 years later some things have changed. Now we have service workers in a seperate thread. And we have await/async functions. But yes, this talk makes the things clearer to understand. thank you!
When I watched this video, I knew it would prove useful for my work. Less than a month later, it happened. Thank you for the great presentation!!
Really, Amazing talk, bro! :)
Once I came up across a scenario where calling a function, say "func()" did not work rather, setTimeout(func, 0) worked!
Now, I understood the reason completely!! :)
I just pause while watching to recheck the speaker's name, wondering that we still have such great speakers.
This is by far the best tech conference talk I ever watched in my life!!
Wow... amazing lecture. The way he is explaining is great. I wish a whole JS course should be taught by him.
This video is life-changing! Thank you for this, Philip! It takes great understanding to explain complex things in simple ways. And thank you for not gatekeeping - we need more people to come into tech and videos like this make sure that even noobs understand and can work with seemingly hard concepts!
There are really no words to say how great this talk was. Amazingly clear, fun, and straight to the point.
The intro music tho.... I turned off the lights and got my glowstick game on. He's amazing. It was an excellent video. My ADHD did not kicked in ever while watching it. 10/10. Will buy again.
One of the best videos on event loop I've seen. The examples, animations of queue and stack are very clear and I've got almost everything, although I'm just starting to learn async functions in JavaScript
Thank you for this great explanation!
thanks @Philip Roberts first time I completely understand event loop :). If you have some other video on js please share.
Javascript Understanding the weird parts
@@aishahale5504 Different author.
@@NishadAhsan Yes, try it.
This is by far the most informative and accessible talks about asynchronous functionality in JavaScript. Thanks, Philip, for showing us the light.
One of the best js videos till today. I wonder it was uploaded 8 years ago. If i would have watched then I would be that much AOT (Ahead of time).
This was my introduction to great conference talks, and, I really believe, one of the experiences that turned me from hobbyist to developer.
8 years down the lane for this video, current in year 2023. Buffering through many videos on event loop still find this one the best. The energy of this man...can feel it on screen as well. Wish i could attend his session once in my life in person.
@19:18 you can see his history. I found it reassuring that a guy with this level of knowledge still has to look up the syntax for Date(). :-) Great dissection of the event loop.
Good example of why code interviews that just test how well someone has memorized various language apis/functions are an ineffective way to determine the candidate's knowledge :)
@@timeslowingdown None of those tests actually check if you have those things memorized. All those tests are there to see how you look for the best available solution
@@lighterinthestorm Finding the solution to a single function with input and output is very different than writing an entire application or maintaining it, so I beg to differ
That's why Incognito Mode exists
Remembering the correct parameters for a function in a library is not a prerequisite for being a good developer, in the same way that needing a calculator in a math exam doesn't mean you're cheating. If you like calculating or memorising sure go ahead, but if you're lazy it's fine
I find myself coming back to this talk as i progress in my career as a JS developer. I think this is my third time watching it, it gets better every time. Well done.
I have been trying very hard understanding this whole JavaScript event-loop, callback, and asynchronous concepts for WEEKS (and failed), despite tons of google searches, article readings and tutorials. I think I finally "got it" after watching this video. So thank you SO MUCH for the talk Philip!!! (and thanks for sharing this JSConf!). I sense "hope"... in understanding and using JavaScripts :)
It's true!
This might be one of the best lectures/presentations I have ever seen. So clear and makes the topic easy to understand. Fabulous work!
This has to be one of the best explanations out there about the event loop.
I've literally read many articles trying to understand this very well, but now I think I do. His explanation is amazing.
2019 and this is still awesome. Great explanation!
Great explanation! Just one note: at 23:35 , lines 12 and 13, I think it should instead be
array.forEach(function (i) {
setTimeout(cb, 0, i);
or else the array element will not be passed to the callback and console.log() will log them as 'undefined'.
+kwstasl2 Thanks!
***** You're right
Yeah, thanks
Just came from Theo t3. I’m a web dev fresh out of college with about 5 months full time experience. This was awesome. Still teaching us almost 10 years later!!
This is absolutely a marvelous explanation of event loops within javascript. It doesn't get better than this, thank you.
Do you know what the ppt is made by? I like the ppt style(animation most). but i think the microsoft ppt is so heavy
Ye Shiqing its made in keynote
Philip describes the event loop mechanism in a perfect way. Lots of love and respect.
This will no doubt remain a fantastic presentation well into 2020 and beyond. Thank you, Philip!
I love this talk so much. Can't help but keep coming to watch again every few months.
Watched it at the end of year 2020 and it is still one of the best in its kind to explain the event loop.
0:58 - How does JS even work?
2:43 - JavaScript Runtime
3:39 - Bigger Picture
4:06 - The call stack
6:54 - blowing the stack
7:24 - blocking: What happens when things are slow?
8:58 - Why is this a problem? because, browsers.
10:25 - the solution? asynchronous callbacks
11:49 - Concurrency & the Event Loop
12:25 - browsers are MORE than just the runtime
12:56 - demo with async code (web API)
14:55 - setTimeout with 0 timeout
16:15 - XHR Web API (AJAX request)
18:15 - loop demo
19:57 - setTimeout & minimum time to execution
20:22 - callbacks
22:41 - Render Queue
24:50 - scroll handlers
the gareth bale of js!
so great!!
was thinking that he looks like Gareth
Exactly !!
🤣
😂😂
Thank you phillips. i been programming from 12-14 years. never come i across to understand event loop. thank you so simply explained.
Finally it took a non-science graduate to explain this to me! Bravo Philip. God Bless u. Struggling with this simple thing for sooooo long!
Interesting how no textbooks mention this stuff wich in my opinion is crucial in understanding core javascript and especially closures (especially when every example on closures out there contains *for* loop with setTimeout and never explains or even mentions event loop and why does *for* loop first finish its iterations and then invokes setTimeout callbacks)
I just made the connection with what you're saying! It finally makes sense!
What he means is that a very common practice question given to novices to see if they understand closures is the following:
const arr = [0,1,2,3];
for (var i = 0; i < arr.length; i++) {
setTimeout(function() {
console.log('index ' + i + ', value: ' + arr[i]);
}, 3000);
}
//Prints 'index 4, value: undefined'
The issue here is that because var is function scoped and not block scoped, i will break out of the loop when it hits the value 4 (as i will now equal arr.length, breaking the test of the for loop). As index 4 is out-of-bounds, it returns undefined as the value for arr[4]. Closures via something like the let keyword mitigate this problem, however. So the test in question is to see whether or not the novice understands the issues of closure with var versus the new block-level variable definers: let and const.
Javascript: The Good Parts by Doug Crockford explains closures very well. Also function-orientation. Other core JS lang features, but not the event loop.
@@johnb1391 Or maybe a less granular way to explain it is: once the for loop is done setting up the setTimeout callbacks, it is finished, and the variable is at its final value of 4. Meanwhile the callbacks run for 3 seconds each, and they are still active - when they print the value of i, it is always 4 (unexpected). You can create closures around the timeout function value to keep the value of i as it was when the callback was created, by either passing it to a function outside of the loop to create the callback, or just making that setTimeout function an IIFE - immediately invoking it creates the closure while the i is still at its iterative value.
Well I guess that was more words lol. Is there any simple way to explain closures?
@@stormwarrow thanks that's a great explanation,, can you include some code examples for "You can create closures around the timeout function value to keep the value of i as it was when the callback was created, by either passing it to a function outside of the loop to create the callback, or just making that setTimeout function an IIFE "?
I wouldn't be able to say how much of a help this explanation has been to my JavaScript understanding.
Of course, I know now that might be 'cause the callback in charge to say such thing is waiting for the stack pile to be empty.
Talk about boss mode, great work by Philip! The loop tool he created is amazing for helping to visualize the runtime, event queue/loop and web api! I can only imagine the time that went into creating and researching how to build it and you can see by his facial expression how much of a challenge it must have been hahah!
Honestly, your explanation is down-to-earth for the understanding of
all. Great work!
Рассказ, понятней чем этот мне ни разу не встречались. Спасибо большое за видео и за перевод
I remember I watched it back in 2016, and now in 2022, I came back to check if it was as good as I remember, and... yes, it's definitively is. There's a real good stuff here, congrats Philip!
For videos like this, youtube should implement a multi-thumbs-up system.
They already do, how else you think Fake news is so "Popular" these days
@@RockDavid I think you misunderstood what he was meaning.
@@coldblackice I think you misunderstood what he was meaning.
@@RockDavid ?????????
This is better than anything any professor have ever done to explain anything to me in university.
I randomly watched this video a week or two before I went on a job interview five years ago. The event loop came up in some advanced JS discussion and I'm convinced it's a big part of why I got the job. Got another interview coming up and I figured I should probably revisit this just to make sure I still remember it. Still just as informative as I recall.
Great explanation.
Its not just the content of the video that is amazing but also the slides are done so nicely and as a speaker i know making a simpler presentation on a technical topic is very hard. Kudos Philip!
oh, that was in 2014 and I thought it is the latest talk, amazing!
OK, I just finished watching this 20 times in a row and now, I finally have it fully memorized. Can't wait to recite it all to my next interviewer.
This lecture is just a masterpiece
This video was an absolute gem - 26 minutes well spent! Thankyou so much for this.
worth every second, watching it the second time.
This probably the best explanation in layman terms I've seen on any tech related videos.
The timeout is executed in the WebAPI right? What does that means? WebAPI executes in another thread? or why the code running in the Web API (section?) does not block the unique Thread JS has or does JS have other threads in the background?
Federico Rodriguez The most upvoted answer here will throw some light. qr.ae/ROfg32
+Bernardo Leon Yup there is a dedicated thread for the event loop and a bunch of threads in a thread pool to handle the callbacks. The thread pool is transparent and is not meant to be accessible from any JS constructs. However as of lately we have Web Worker thread pool progammatically accessible to JS to offload long running CPU and I/O intensive work to a different background thread pool.
Thank you *****
Trying to answer all your questions
The timeout is executed in the WebAPI right? - Correct
What does that means? - It means the *timeout* code is running as part of a different part of the Browser process (Chrome, Firefox). It is *NOT* running within the Javascript section
WebAPI executes in another thread? - It runs in a different area of the browser process and it able to run concurrently with the code that is running on the Javascript side
or why the code running in the Web API (section?) does not block the unique Thread JS has or does JS have other threads in the background? - The browser is able to run multiple things (the WebAPI, the event loop, the rendering engine and the Javascript processor to list a few) concurrent. But the JS processor does *NOT* have other threads in the background, in its limited view it can only do one thing at a time which is defined as what's one the top of the call stack
@@TheBohrabohrafamily Thanks, I was suspecting that the "it runs in another thread" explanation was incorrect. n.b: The distinction between concurrency and parallelism is an important one.
The reason why this video is so awesome for many people, is cause he really had the doubts a truly beginner has.
Amazing,!! the best and simplest explanation I've seen, thanks
I'm watching this in 2021. I overlooked this video because it's old. Well I came back because I was disappointed with all the other more recent videos I watched. The speaker here did an excellent job at simplifying the topic. I'm so glad I watched this. I just hope it is still very relevant today. I can't imagine much has changed.
brilliance! Absolutely stunning. Thank you
Some explanations are so good that you understand the concept crystal clear. It really sticks with you, thank you.
This video has helped me cracking interviews!! Thanks Man!
Still watching this in 2020 and has made JS clearly than anything, and the joke at ~ 17:30 was great to see. Shows personality and gives an almost Steve Jobs feel. Top draw.
the best video ever seen. it's still awesome in 2019!
Brilliant. No question that this talk opened up new doors for this young man.
So no one bothered to ask if JS is single-threaded, how can it also, in parallel, maintain an event-loop. The event-loop is actually provided by the browser.
lol.. thanks for the info
honestly this is the best convo about js runtime ive ever listened. thank you phil!
this guy said he no computer science guy! can't believe it with such explanations thanks alot
hi from student in Yandex-Praktikum web development courses in Russia. For me as a beginner to understand how js works, this video was very informative. so thanks for him and all the best
Excellent presentation! 👏👏👏
this video is pure gold. thank you philip for creating the tool and this video.
Omg when did Gareth Bale started to code, this is amazing
You've explained in 30 minutes what hours of web searches didn't really explain clearly at all. Thank you! Also @17:05 made me lol
best explanation ever ! literally
Honestly, I watched it last night while sleeping but the way my guy explained was so good that I am still thinking about the diagrams he showed this morning!
came here redirected from async npm package docs... how come i've been doing things without knowing about this? Really useful, Thx
I share this with all of my teams. I think its the most overlooked and valuable things a js dev can learn
I have one doubt - If task queue waits for whole call stack to gets cleared up, then all async callbacks should execute after the whole program is finished. Since the main() is at the lowest level in the call stack? So if we run something in react like setState, it should be executed in the end, which doesn't happen. What am I missing here?
Jasveer Singh, if you now figured out the answer can you wright about it? I also have some problems with understanding setState in event que
2 mins into the video i thought let me skip this but then i watched it fully and now i am glad that i did