쉐도잉 연습: JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue - 영상으로 영어 말하기 배우기

The event loop is a pretty notorious topic in JavaScript, but when we zoom out, it's just a tiny component within the JavaScript runtime.

We also have the call stack, we have web APIs, we have the task queue, microtask queue, and then eventually the event loop.

Well, to be a little more technically accurate here, we actually have the JavaScript engine in which we have the call stack and then also the memory heap.

But to keep my slides a little organized, I'll just be showing the call stack here.

All these components together allow us to use asynchronous tasks in a non-blocking way in JavaScript.

And this is important because JavaScript itself is single-threaded.

We're only working with a single call stack.

So the call stack manages the execution of our program.

So if we have the following script, we first have console.log1.

So a new execution context is created, pushed onto the call stack, which is then evaluated and logs 1.

Then we have console.log2, same story.

Execution context is created, pushed onto the call stack, is evaluated and logs 2.

Then on line 14, we invoke another function, the log3 and 4.

And within this function body, we invoke yet another function, log3.

And within log3, we invoke another function, the console log3.

Eventually, it logs 3.

Then on the second line, within the log3 and 4 function body, we console log4.

4 gets logged.

And now the log3 and 4 execution context is popped off the call stack as well.

Now, something important to remember here again is that JavaScript can handle a single task at a time.

So if we, for example, had this long running task in which we have a pretty heavy computation, it takes a while before JavaScript can continue with the rest of our program.

So the console log long task done is only logged after a couple seconds.

And this is not what we want because in the meantime, our entire program is frozen.

So we want to avoid these long running tasks.

But in a real life application, we often have to use these long running tasks, like maybe a network request or anything based on user input, timers.

So what happens then?

Like, is our entire call stack just blocked until we get the data back?

No, because we're actually using web APIs in those cases.

And web APIs provide a set of interfaces that allow us to interact with the browser's features.

This includes functionality that we often use, like the document object model, fetch, set timeout, and so many more.

The browser is a very powerful platform with a lot of features.

Some of these features are required like the rendering engine

or the networking stack

but we also have access to some cooler ones like device ones sensors cameras geolocation

and so on okay cool

but what does this have to do with long running tasks

well some of these web apis allow us to offload long running tasks to the browser

so when we invoke such an api we're kind of just initiating

that offloading and web apis that expose these asynchronous capabilities are either callback based or promise based.

So first let's focus on the callback based APIs and I'm just going to use the geolocation API because it's fun.

I could have used any other callback based API, but let's say that we want to get the user's location.

And for this, we can use the get current position method exposed by the geolocation API.

And this receives two callbacks.

First, we have the success callback in case everything goes well

and the user allows us to get the location and we actually get it from the browser, or the error callback in case anything goes wrong.

So let's see what happens when we actually use this in our script.

So first, the getCurrentPosition invocation gets added to the call stack.

However, this is just to register those callbacks and initiate that async task.

After doing that, it can get popped off the call stack immediately, so it doesn't wait for any data.

Now in the background, the browser starts some kind of process that eventually shows the user pop-up.

Now of course we don't know

when the user is going to interact with this pop-up

but that's not a problem because this is not happening on the call stack

so our entire website is still responsive in case other tasks need to run instead.

Now finally the user clicks on allow.

So the API receives the data from the browser and uses the success callback to handle this result.

However it can't just push that callback back onto the call stack.

This could disrupts an already running task can just create very unpredictable behavior.

So instead, the callback gets pushed to the task queue, which is also called the callback queue for this exact reason.

The task queue holds web API callbacks

and event handlers to be able to get executed at some point later in the future.

And this is where we finally get to the event loop.

It's the event loop's responsibility to check if the call stack is empty.

And if that's the case, so if nothing is running, it then gets the first available task from the task queue and moves this to the call stack where it's executed.

So now finally we handle the results and the user's location is logged to the console.

Another very popular callback-based web API is setTimeout.

And setTimeout also receives a callback and a delay.

So let's see how that works.

So first we encounter a setTimeout and this again gets added to the call stack

but all it does again is register that callback and also the delay with the timers API.

And in the background the browser will actually handle that timer.

Then we have another set timeout and again It registers the callback

and the delay now our timers are still running

and we have a console log end of script This just gets added to the call stack

and logs end of script nothing asynchronous here now after a hundred milliseconds The browser's like hey a hundred milliseconds expired.

So now the callback moves on to the task queue There's nothing on the call stack right now

So this moves on to the call stack where eventually it logs hundred milliseconds

now 2 000 milliseconds are up again same story the callback

is pushed onto the task queue call stack is empty

so it moves onto the call stack where it locks 2 000 milliseconds

so it's just very important to remember that

when you have a set timeout

and a delay it's not the delay until it gets moved

onto the call stack no it's the delay until it gets moved to the task queue

so this means that the delay

that we specify might not actually be the delay to execution

because if call stack was still very full with other tasks

and this could run for many more seconds the callback would

still have to wait in the task queue until the call stack is empty

so just something to to keep in mind

so long story short the callbacks provided by web apis are pushed onto the task queue

when the asynchronous task completes so what about the promise based ones

if you haven't checked out my promises video yet i highly recommend you watch it

because i'll just assume some basic promise knowledge

while explaining this entire flow whenever we work with promises we're

working with the micro task queue the micro task queue is

a special queue dedicated to then catch finally callbacks a function

body execution after a weight the queue micro test callback

and the new mutation observer callback so only those callbacks

100

or those function body parts get pushed onto the micro task queue

101

so it's very specific however the event loop prioritizes the micro task queue

102

so whenever the call stack is empty the event loop first ensures

103

that the micro task queue is entirely empty

104

so it gets all the tasks from the micro task queue

105

moves them onto the call stack where they get executed

106

and only then will it move to the task queue

107

and after each task in the task queue it again checks the micro task queue

108

and a popular promise-based web api's fetch

109

so let's see what happens behind the scenes when we invoke fetch

110

so whenever we call fetch it's added to the call stack this is just responsible for creating a promise object

111

which by default is pending the result is undefined

112

and we don't have any promise reactions just yet it also

113

initiates the background network request that's handled by the browser then

114

we move on to the next line we have the den handler

115

and this creates a promise reaction record where we have res

116

console.log res the server still hasn't responded by the way

117

but we get to line four So there we have a synchronous console log end of script.

118

So now end of script is logged to the console.

119

And then finally the server returns some data.

120

So now the promise state is set to fulfilled.

121

The promise result is now the response object with the data that we got from the server.

122

And the promise reaction handler is now also pushed to the micro task queue, right?

123

Because it's a then callback and that gets pushed to the micro task queue.

124

The call stack is empty.

125

So the event loop checks the microtask queue, moves this to the call stack where it eventually logs the result that we got from the server.

126

Something to keep in mind with microtasks is that a microtask can also schedule another microtask.

127

And this means that the event loop is just constantly handling the microtask

128

and it can never actually get to the task queue.

129

It would just have to wait indefinitely.

130

So we're kind of creating an infinite loop, an infinite microtask loop, freezing our entire program.

131

I believe in node you can set like mextick depth

132

or something like that which prevents this exact thing from happening

133

but just make sure that you don't accidentally end up doing that.

134

And we can also promisify a callback based API.

135

So for example we can rep the get current position with a new promise constructor

136

and for the success callback and the error callback we just pass resolve and reject.

137

So this can be a pretty nice solution just to improve the readability within your code base a bit.

138

All right, a little quiz to see if you kind of understand it.

139

So we have a promise resolve with a den handler.

140

We have a set timeout.

141

We have a QMicroTask in which we have another QMicroTask, and then we have a console log 5.

142

It's up to you to see what gets logged.

143

So pause the video now and let's see if you got it right.

144

And the right answer is 5, 1, 3, 4, 2. So let's see why.

145

First, we have the promise resolve, and this just creates a new promise object that's instantly resolved.

146

Then on the next line, we have the den handler.

147

The promise is already resolved, so in the background, it does create that promise reaction, but the handler is immediately pushed to the microtask queue.

148

Then we have setTimeout, which is responsible for initiating that timer.

149

So the callback and the delay get passed to the API, and in the background, the browser starts some sort of timer.

150

Then we have queue microtask.

151

So the call is added to the call stack and this queues that callback to the microtask queue.

152

Then we have the synchronous console log 5.

153

So this gets pushed to the call stack and logs 5.

154

And in the meantime, the 10 milliseconds are up.

155

So the callback from setTimeout is pushed to the task queue.

156

Because this was a callback-based API, so task queue.

157

Our script is done.

158

The call stack is empty.

159

So the event loop checks the microtask queue.

160

And there we have the promise handler callback.

161

And this eventually calls console log 1.

162

So 1 is logged to the console.

163

Then we have the queue microtask callback and within this callback we call console log 3.

164

So 3 is logged to the console.

165

Then we call another queue microtask and this queues another microtask with its callback to the microtask queue.

166

However, the event loop has to ensure that the microtask queue is entirely empty before moving on to the task queue.

167

So that callback is immediately moved onto the call stack again and logs 4.

168

Now finally the call stack is empty and the microtask queue is empty

169

so the first available task from the task queue is moved onto the call stack and this eventually logs two.

170

So now we have 51342.

171

So let's just recap what we've covered so far.

172

So JavaScript is single-threaded.

173

It can only handle one task at a time.

174

We can use web APIs to interact with the features leveraged by the browser

175

and some of these APIs allow us to initiate async tasks in the background.

176

So the function call that initiates an async task like

177

that is still added to the call stack

178

but this is just to hand it off to the browser the actual async task is handled in the background

179

so it does not block the call stack the task queue

180

is used by callback based web apis to enqueue the callback

181

once the asynchronous task has completed then we have the micro task queue

182

which is only used by promise handlers the async function bodies after awaits the queue micro task queue callbacks

183

and the new mutation observer callbacks.

184

This queue has priority over the task queue and the event loop ensures

185

that this queue is entirely empty before moving on to the task queue.

186

And after handling each task from the task queue, the event loop again checks the microtask queue to ensure that nothing has been added in the meantime.

187

You often come across asynchronous JavaScript and if you aren't entirely sure why things execute a certain way, it might just be very discouraging.

188

But I hope Hope that my explanation for the task queue

189

and the micro task queue

190

and the event loop kind of helped you understand why certain parts of our code execute at a certain time.

191

Of course, as always, if you have any specific questions, feel free to reach out.

192

But I also highly recommend that you kind of just play around with it yourself.

193

Like try using setTimeout, try using queue micro task just to get a better sense of like, oh yeah, okay.

194

I understand why this runs at this time and why this doesn't execute stuff like that.

195

Good luck and have fun coding.

✨ 추천 영상

345 문장

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법

쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.

섀도잉 방법: 단계별 전체 가이드 읽기 →

쉐도잉 연습: JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue - 영상으로 영어 말하기 배우기

What the heck is the event loop anyway? | Philip Roberts | JSConf EU

Video

PLC Programming #4: Functions, Function Blocks & Organization Blocks Explained

🚫 Java Deadlock Explained: Why Your Code is Stuck 😱 (Beginners Must Watch!)

Your AI broke the layout. Now what?

Ricardo Vargas Shows How to Implement Governance During Project Execution

Array Map in 100 Seconds

S3 Speech1 short

Does Anyone Use JavaScript Anymore?

The GELU, SiLU and SwiGLU activation functions, clearly explained!!!

Database Sharding! Designing Data-Intensive Applications chapter 6

My Vibe Coding Workflow (Step by Step Workflow)

이 영상에서 배울 실용적인 영어 스피킹 기술

듣고 주목해야 할 발음 특징

원어민처럼 말하는 방법: 리듬과 강세

쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법