 Hello everyone, about three and a half years back when I was actually interviewing for Amazon in one of the questions, so in one of the rounds, one person comes up to me and sort of asks me a question which kind of left me fumbled from there on. He asks, so he was silent for about five minutes and then he asks, what makes programming interesting? And I was like, okay, and there was a silence for a few minutes. And then that particular question kept me thinking ever since what makes programming interesting? What makes you sparkle at the end of a good program that you have delivered? And I kept on thinking about this problem for a while and it kind of took me a couple of months to figure out a particular resource which actually helps you visualize that So I sort of like almost went back 30 years and took this course. This course is really available. This course is from MIT and you can find it in MIT OpenCourseWare. But after taking the course, I again thought about the same question. What makes programming interesting? And I think I have kind of sort of like got two parts of the answer and it's definitely my own opinion. But in general, if you think about it, there is a science part of a programming and there is the art part of a programming. If we talk about the science part of a programming and then sort of like try to reason what makes programming interesting? What you have to kind of understand is that first of all, programming is an abstract concept to begin with. Unlike a real engineer, electrical engineer, when he is designing electrical system, he has to think about the physical constraints of the real world, like the noise, the heat, the other jitters in the overall system. That's actually not true when you are kind of programming, right? You have an idealized component. Think about this, if I as an electrical engineer can go ahead and build a two-stage amplifier very easily. In fact, I can build a three-stage amplifier also very easily. But then if I think about cascading all those amplifiers to sort of like make a million stage amplifier, that doesn't make sense. Because by the time you get that amplification, the actual hindrance and the noise and the heat and all other aspects of the physical constraint will make the whole system meaningless. That's actually not true for programming. When you have a programming which is abstracted out, you can sort of like use it and reuse it and reuse it in a very pure fashion which doesn't change. You are kind of in a world where sky is the limit. On a different aspect for the science part only, it also helps you manage complexity. Now, any typical application in general sort of like consists of like what, thousands of lines, at least minimum for a viable application. No programmer can actually sort of understand all those lines of code in one go. So what you have to sort of like think about is that it also helps you to build powerful abstractions where you can ignore things and sort of like focus on the big picture. And then you can compose those abstractions even more to build even higher abstractions and you can use them and reason about them in a way. So that you still have the purity where none of these physical constraints are affecting your programs. But that's the science part of it. If you think about the art part of it, the way I would like to think about the whole problem is it's like chess game. The rules of the game in general is so easy to learn, somebody can learn them in half an hour or one hour. But then if you have to become a master chess player, it takes years and years of rigorous practice, understanding the implications of your moves. In fact, sometimes you have to think ahead your moves and sort of countermoves as well. In that sense, programming is very similar. And this is where this talk kind of belongs, where you have to understand the implications of what you are writing. Every piece of code that you write has some implications. And as a good programmer, you have to understand those implications. If you do understand those implications while you are coding, you can think about what you're doing. Does it make sense in the context or not? And in a way, these two pieces put together makes programming so interesting. So I would definitely encourage each and every one of you to take a look at this course. But today we have picked JavaScript for the same exploration. And what we will do is we'll pick up a piece of code, a very simple code. It's nothing sort of like rocket science there. And we will walk you through that code as if it's getting executed in a machine. And we will sort of like see what happens inside. And we will try to see how this cryptic concepts like variable, hoisting, closures, scope chains, and so on and so forth, even for that matter, event loop and async programming actually makes sense. When you get down to that first principle, when you get down to a program and you literally execute it as if you are the runtime. Can somebody help me with this? Actually, I need this. Hold on. This is on. That's fine. I'll just start over there. So today's agenda is very simple. We will sort of like walk you through a piece of code line by line and sort of like show you how all these things actually fit together. These things are jargon things. These things, it almost when I started programming JavaScript about six years back, I couldn't understand any one of them. And after that question was raised, it actually helped me think about these things that even if you understand things as an API level or a programming concept level, it's very important that you understand the implications how they actually get implemented at the runtime. And this helps you not only to understand the programming language in a better way, but when you program, it also helps you to understand what you are writing, what are the essence and the implications of that. So after this, I'll immediately switch to coding without wasting any more time. I have a very small piece of code which I would like to run through. All right. So we're gonna spend a couple of minutes here. So I would like to focus on this code here. This code has a lot of gems in it. What we will do is we will run through this code line by line and we'll see how exactly memory allocation, how exactly execution and all other things are happening inside the runtime. Now, this is a hypothetical runtime. Now, you cannot just say that v8 or any other JavaScript runtime implements it in exactly the same fashion, but any JavaScript compliant language is supposed to behave in a consistent fashion which aligns with this. Also, before I begin, what I would like to say is that JavaScript, in general, not a lot of people knew about this. I also myself didn't know about this, has a compilation phase. It's a two pass thing overall. I didn't know about this. I always thought that JavaScript is a load and go system. In fact, it is a load and go system, but it's unlike any other interpreted language it's different. Think about a shell script. When you are executing a shell script, the line you are executing, the next line, whatever it is, the interpreter doesn't even have a clue. JavaScript is little different. Even if you sometimes get errors which might have been caught if it would have been compiled completely, but then it still goes through a compilation phase and then an execution phase. And we'll see what the importance is. So whenever you see an arrow on the left side, that's the line I'm talking about in the code. And whenever you see a red arrow there, we are going through the compilation phase. This arrow turns green whenever we are kind of entering the execution phase. Let's see how this code executes actually. And also one more thing is when JavaScript goes through the compilation phase, it actually just extracts out the declarations, the variable declarations, the function declaration and prepares the memory so that it can execute the code. Let's see how this code actually runs. So we are at line number one and we have a declaration called var a equal to two. Now we are going through the compilation phase. So the value doesn't matter. It just looks at the code and says that I have a var a which is a variable declaration. So I will allocate a memory in the global scope for a. I have the variable a as the reference. I don't have a value yet. Then when it moves to line number two, it says that no, no, no, this is not a variable declaration. I don't know this. I will just skip this part. It goes to line number four and there it actually sees that a function declaration is being made. It's a new function which is declared in the scope. So it just gets a reference of f there. And then something interesting happens. Whatever is inside of f, the compilation is actually just checking for syntax and then skips over everything else. It directly moves to line number 18. Now in this phase, what actually happens is that whatever is the content of this function is put together as a string blob if you might want to imagine it. And then puts it somewhere in the memory and have a reference of f there. At this point, it doesn't even know that a function g exists or not in the system. Very important to understand this part. Now it goes to line number 20 and then there is no other declaration, right? There are no other declaration in the code. We are done with the compilation. So after the compilation is done, this is the situation in the global object. You literally have a reference for a, a reference for f. And f is pointing to some text object in memory which I'm calling at this point lambda f. Now the execution begins. So after the compilation is done, immediately the execution begins. There is almost no lag. Once you try to execute, then it kind of ignores all the var and other declarations. It tries to execute the code. So here it says that a equal to two, so the value two gets assigned to a. Similarly, when it goes to line b over here, now the question, the actual question in the execution phase, because in the compilation phase, you have already gone through all the declarations. In the execution phase, what JavaScript runtime does is it asks the memory, do you know what b is? And here the answer is no, I don't know what b is. Only exception in JavaScript for this situation is if you are in the global scope or windows scope or for that matter global scope in node. JavaScript is forgiving in the sense that even if you don't have a reference for a variable, and you are trying to assign a value to it, it creates that variable for you. But what you have to understand is this part happens at runtime, like execution phase, not at the compilation phase. So it has created a variable b for me, which come after f and then assign the value one there. Then there is nothing to execute. It directly hits line number 20. When it is actually hitting line number 20, now it has to execute f. When it has to execute f, at that time it creates a local heap memory and then sort of prepares an execution context for f. Now here it differs from most of the other programming languages. For example in Java, which is like completely stack-based language, every function invocation kind of keeps track of all the local variables and everything in stack. JavaScript also has a stack, but that contains only very minimal information. It contains the written address of the function and it contains a reference to this memory which will be allocated in the heap. And for all other things, it keeps the things in heap. There is a reason, there is a very good reason why it happens and we'll come back to that. So before it enters f, it actually kind of creates this execution context or memory allocated in heap for this. And then it enters f. But when it enters f, it actually enters into compilation phase again. We are switching gears. When it sees f and f takes a parameter z, what you have to understand is whenever a function takes a parameter, it's also a local variable which is declaration. So this is declaration. So z gets declared here as one variable and then b, c are skipped because there is no compilation required for that. And then it hits another declaration radii and you allocate d over there. It hits another declaration z and it does exactly the same thing that we talked about. It doesn't even go inside z to see what is inside z. It skips over that. It just creates a blob for you and keeps a reference there. And then as we are going through compilation phase, it also hits another var e as an statement. Even if here we have a written statement which is above var e, so we are sure that this var e will never be executed because you have a written statement. But as JavaScript goes through a compilation phase, this is very important. That's why a local variable e will be actually created as a reference without a value. As JavaScript is a two-pass system. And this is where we see variable hoisting. A lot of things say that variable hoisting. All the declarations that you have made will be sort of pulled down at the top of the function and sort of like defined there. This is why that happens. Are you clear? Good. After this, we have no more declarations, right? So our compilation of f is done. We enter the execution phase for the same function. Now when we enter the execution phase, what is past of f is one. So z becomes one here. On a similar fashion, when it hits b equal to three, imagine what happens. Oh, one more thing I forgot to mention. So whenever the local execution scope of f is actually created, there is also one pointer created from the actual execution scope from which this heap memory got created. So think about it like lexically defined. Whenever f gets executed, it kind of has a back pointer to the outer environment it has. We'll come back to this pointer as well. This pointer is also very important. But imagine what, how exactly line five will be executed. As far as the JavaScript runtime is concerned, it will ask the same question. Hey, do you know what b is? And you are in the local execution of f. F says no, I don't know what b is. At that point, it will try to follow this pointer all the way back to global scope and like no matter how many chains still it kind of finds the definition of b or it hits the global scope at that point of time whether you have a reference of b or you create new one. A new one. So when it kind of figures out that b doesn't exist at f, it goes to the global scope and there it says that, oh, I know what b is. Its value is one. And it says that, oh, no, no, no. Now b should be three. So b gets reflected three on the global scope by this line of code. Similarly, when c equal to four is actually executed, again the same question is getting asked for local execution of f. That do you know what c is? It says no, I don't know what c is. It goes to the global scope and global scope also says that I don't know what c is. And as you are at the global scope and global scope is a little forgiving, so it creates a variable c for you and assigns a value four there. Then you have b equal to six. As I said, ignore the var because we are at the execution phase. Here you see that b is six is actually reflected at the local scope of execution for f. And then this was just a definition, so all ignored and equal to one as well. And then you have a written statement which is like g function execute itself. The moment you have a call, again the same thing happens as I talked about. And a heap memory gets allocated for execution of z and then we enter a compilation phase for z. When you enter the compilation phase for z, as you saw lexically there is a pointer back to local execution scope of f and that's pretty much over it. And it goes through the compilation phase. When it goes through the compilation phase, you are hitting var e equal to one declaration, only var e equal to zero, e gets defined there and then compilation is done. Execution begins immediately and in the execution phase, e gets defined to be zero. Now, what you have to understand here is that when you are at z, when you are inside of z, every time you ask for e, you will get the locally that is already defined in g. So even if you have a pointer which points back to f and f has a definition e, every time you ask for e inside of g, you will never get access to this e. You will always hit the locally because of the scope resolution, that's how the variables are kind of resolved all the way back to global, right? This is where this e equal to one in f is completely hidden. There is no way you can access it. And this is called variable shadowing in JavaScript. This is a very important concept. Kind of trips a lot of programmers when they are in a situation like this, and they are trying to access a variable with the same name, which is somewhere up in the scope chain. Then the next line gets executed, which is d equal to three times d. And similarly, the same question gets asked for g. Do you know what d is? I said, he says no, I don't know. It follows the pointer back to f, says that do you know what d is? He says yes, I have a definition of d and the value is six. He said do it three times of that and sort of like assign it to the same variable. It does 18 over there. And now we are done. It hits the return d, which is the value 18 itself. You go back to line 16, where the g call is now replaced with return 18, and then f of one, which is 18. After f of one is done, what you have to understand is all these function executions are done. There is no work left. Now, for the sake of this program, what I have said is that if you would have had more code over here, only execution scope or only scope you would have had is the global scope. So I have kept it there as if you have a reference to it. But for rest of the things, there is no reference. There is no reachability. In JavaScript, if you have an object or a function definition or a function execution, no matter what type of things you are talking about, if you do not have a way to reach there, it will be garbage collected. For other programming languages, sometimes it's based on reference counts, sometimes based on other aspects of it. In JavaScript, it's purely based on reachability. If you can reach this code somehow, it will not be garbage collected. If you cannot reach the code, then it will be garbage collected. So here you see that all these definitions and sort of like heap memory is garbage collected at this point of time. If your program final line would have been 20 only, then this would also would have been garbage collected and you would have exited from main itself. Let's modify this program a bit to make it a little bit interesting. The only modification we are doing here is instead of calling g as a function itself, I'm returning the function object. And then in the global object here, I'm declaring one more variable called my g and sort of getting a reference back of that function over there. It's a very similar function. Ultimately, the result also will be the same, but the memory allocation will be interesting now. Let's run through this code also sort of line by line and we'll skip for the most of the boring parts and we'll sort of like focus on the interesting part as we have gone through line by line already. So we start at the compilation phase where a equal to two and similarly, all these things happens. So after the compilation is done, you have to understand is my g one more variable gets created in memory for global scope. That's all. Once that is done, let's execute it in a similar fashion till you hit the interesting point. We will hit the interesting point here where you have the return g statement. So all other things has happened. Everything is good so far. When you have return g that gets assigned to my g. What happens is basically you have a pointer like this. Makes sense? You have my g pointing to the function definition g which is the lambda g itself which earlier g used to point to. And then when you actually call my g a very similar thing happens. You get the execution environment. You call, you set equal to zero and all other things happens. But after the execution is done, you see if the global scope holds on you have a reference of my g which has a reference of lambda g as well. At this time, the garbage collector will come and only collect the local execution scope of g and rest of the things will be in memory. And this is where closure will come into picture in a minute. So what do you have to understand so far is as far as JavaScript is concerned g is reachable in your code. If g is reachable, it will not be garbage collected. And if it is not garbage collectable, all the aspects of it, all the pointers and the execution scopes and all other heap memory will remain because if g gets executed and if you need to refer to any of these variables, you will need this memory to be already there present. Also you have to understand is every time such functions are actually executed a separate heap memory gets allocated like this. So let's just look at sort of like how exactly this was possible. So in general, this took me a while to sort of like figure this thing out. But what happens is whenever you have a function getting defined. For example, in the global scope, during the compilation phase, I was defining F. At that point of time only, along with the definition where you have F pointing to lambda F, you have a back pointer to the execution scope itself which is called scope. This is sort of like have this drop double brackets because this is a hidden property or a private property. There is no API to access this pointer. It's only accessible through the way we have talked about when a variable reference is missing and sort of it needs to do a lookup. Similarly, when you're executing F, at that time, G got defined in the compilation phase. So it also have a scope pointer back to F. Once you have this thing clear, rest of the things gets very easy. So now every time I have to execute F, what I will do is I will allocate a heap memory and then to know where I should point back to, I will just copy this pointer. Make sense? So here, whenever I'm creating a local execution of F, I'll copy that scope pointer and that will tell me where exactly I should point to in my execution scope, where what is the correct outer environment for me, where this function gets defined. So let's just go back a while and sort of understand this. Here, I'm calling my G from the global scope itself, but G gets a pointer back to F and not to the global scope here. How is that possible? Because lambda G already when it gets defined, it has a scope pointer pointing back to the same reference for F. So when G gets executed, after the heap memory gets allocated, you literally have a copy of that pointer, which makes this pointer back to F possible. Well, this was it. And this is closure, by the way. If you haven't noticed so far, you see my G kind of holds a reference, my G kind of now holds a reference to lambda G. And even if F is long executed and sort of returned, the memory allocations for F are actually not returned because you have ability to call G and G is defined only in the context of F. This is closure as far as the runtime is concerned. Now it makes a lot of sense when you are actually coding a closure and you are sort of like understanding a closure to understand how it holds on to those values. So I'll sort of like give you an example. If I can switch here quickly, I'll sort of like skip through most of the slides we have already gone through. I'll come to the interesting part. So this is the right question to ask when you are trying to understand closure in general. It is confusing to begin with, but the moment you see the memory allocations and how function definitions are actually working, you can relate back all these things. So if you have to kind of say what closure is, it's just an implicit permanent link between a function and its scope chain. Cope chain is what was allocated as a heap memory. That's what you have to understand. Also, this is done by the scope reference. It holds, it is used to be copied as the outer environment every time that function gets called. So no confusion, whenever you have a function definition, it will have a scope sort of like pointing back to its outer environment and that will be the reference every time that function gets called. Now why this closure is so important? Why this concept is so important? To tell you in a brief sense, this is what makes asynchronous programming even possible for JavaScript. Take example of the simplest JavaScript code that you have written. MyData is myData and then you have a setTimeOut call. Think about if you wouldn't have done this by the time your console log is actually executing, you would have lost the data variable itself because your outer function is long gone. But as the setTimeOut is defining a function which holds on to this outer reference and that is not garbage collected, that's why console.log will actually print myData here. Very interesting implicit closure everywhere. All the callbacks that you pass on to holds have an implicit closure. Be it an Ajax call, be it a DOM manipulation, be it setTimeOut, whatever you say. There are other use cases where you can use it as an explicit sort of like use where let's say I define a function makeAdder which kind of, it has only simple function. It returns you a function and then it takes one argument and makes the adder for this. So if I make a adder of three here, every time I call adder three, it will add three to the overall sum and return me a value. Now I don't want my adder to be interrupted by some other program. So I am not exposing any external references to this function. But then when this function gets executed, it creates a closure and I will show you a demo for this. So I have the exact same code here defined. Let's just, let's just see we are having a console here. This is the exact same code we talked about. If you kind of execute this code, I now have a variable called adder three. Every time I call adder three here, you see I'm getting a value which is like three more, six, nine, and so on. Sorry to put this as well, adder three, and so on and so forth. If you want to see what closure is in console, you can do that. The trick is here, if you can, you have to list the function itself. So if I do console.dir and sort of like try to explore adder three here and see what this function has and then if you explore this, you will see that function scope is there and then if you open this up, there is a closure and the closure holds on to those values which were not explicitly accessible by you. Makes sense? If I make another adder, you will see these values will be different and it will be a completely different heap memory which gets allocated for that scope definitions. And for that matter, I can sort of like do that very easily if you want me to. So instead of, let's just do it. What I can do is I can say where adder two is make adder two here and if I just call adder two, it returns me all these things. But what you have to understand is this, the function reference that it has is from a different scope chain altogether and if I do console.dir for adder two, I'll just do that here very quickly. You will see that those variables will be completely different here. Let me just clear the screen. See, these values are different. This is a completely different heap memory which got allocated for this execution environment and then the function definition is on that heap which has a pointer back. That's how everything works in JavaScript and the moment you kind of crack this kind of concept and sort of understand how it works behind the scenes, you can reason about all sorts of programming patterns. For the next part, what I want to do is I want to right away jump into a demo for the sake of time. This is where we kind of build on whatever we have seen so far. This is a visualization which is done by a guy called Philip Roberts. What this visualization is about how JavaScript actually executes code. It's written in a compiler called Esprima. That's a JavaScript compiler written in JavaScript and there are some modifications done to it but just let's just get to the meat of this code. We have a very similar sort of function here, right? Set timeout and console.log high. We want to execute this. Now, in JavaScript, you have heard about all these things called event loop and single threaded and single threaded and parallel and so on and so forth. Let's just fit all these things together. If you actually explore the actual runtime of JavaScript, say v8, you won't find any event loop there. You won't find any set timeout there. You won't even find any DOM APIs there. You won't find any Ajax calls there. The JavaScript runtime itself is just a call stack and a heap, that's all. And that's why as it has only one call stack, it is single threaded and it can only execute one thing at a time in reality. Rest of these pieces of which makes your asynchronous programming possible is actually a part which is provided by the browser in case of Node. These are the C++ libraries which gives you those APIs. So here set timeout is actually an web API. It doesn't live inside JavaScript runtime. And what set timeout does is basically it creates a timer which is outside of the JavaScript runtime and then hands it back whenever set timeout is done. Now, in this diagram, what you have to understand is the call stack is only the JavaScript runtime. That's it. The web APIs are those handlers which makes asynchronous programming possible. For example, set timeout, we will have the onclick events as well if time permits. And the event loop is actually outside of both of these things. This little circle that you're seeing is the event loop. That also gets implemented outside the JavaScript runtime. And then you have a queue called callback queue. The callback queue, what it basically does is every time web API hands them over a task, it just queues them up, that's all. And the event loop's task is very simple. It looks at the call stack for the JavaScript runtime and says that, hey, are you free? If the JavaScript runtime says, yes, I'm free, I have nothing to do, then it looks at the callback queue and say that, do you have anything to be processed? And then it pulls together those things for the call stack to the call stack so that the JavaScript runtime can execute them. Let's take this example. This I will make a set timeout of eight seconds. And then if I just run this, you see first set timeout gets called and then a timeout timer gets added there. Eight seconds we will wait. It will be immediately pushed to callback queue and then callback queues and the event loop will pull it together because the call stack is empty. Make sense? All right, now to add a little bit more complexity to this, do something interesting. So I can also simulate the browser rendering here. So callback queue is one type of queues. You can have multiple queues with different priorities and given a set of tasks that you have waiting on the queue, the event loop will always pick something which is of a higher priority. For example, you can see the render queue just does a paint, paint, paint after some time. It's just simulating that and the event loop is kind of executing it. The visualization is off because we don't even care what the paint function does. Now let's look at a synchronous programming which kind of blocks this rendering. So if I have a process function which inherently is slow, I know that. And I want to sort of like execute it over an array and sort of like do it time and again. Let's see what happens in the runtime. If you just save and run this, see the call stack has that for each and every time you kind of running this function, the call stack is not empty anymore. You have something in the call stack. So the render queue is now blocked. The event loop cannot do anything. So even if you have a slow function or a fast function doesn't matter as long as that for each is running, if you have array of let's say 1000 elements, your render queue is blocked. This is when your browser is like frozen. The user cannot do anything at all and you are processing this heavy function. And there are times when you have these heavy functions and it's a little tricky how we actually get around that. We will solve this problem by making this code only asynchronous. But for the interest of the crowd, the concept of generators in ES6 is precisely this. When you have a long running function, you can explicitly pause them and then signal them back to resume to kind of make this fluidity over here. So you can explicitly say that get a slice of the execution of the call stack in JavaScript, but then don't consume it too much even if you are a long running function. I know that in order to have the responsiveness of the function itself. So this we saw that this is slow. How can we make this fast? Let's just very quickly do asynchronous programming here. And all of these are actually possible because we have those closures and function definitions and all the things that we talked about. My bad actually. In fact, let's just do it here on this. You know, I'll do a set time out function. And I don't have to pass I here because it's outer reference and it will be available through closure to me. And I will pass a value zero. So what I'm saying here is that when you're processing the for each, what do you have to do is you push them into the asynchronous queue. I don't want you to hold on to the call stack for this. And then once they are in the callback queue, process them on after another and at that time, the event loop can actually pick which has the higher priority. So let's just run this code and see how this code actually executes. So the moment you have this, you can see that the for each is executing very fast. I'm sort of pushing them in the wave APIs and they are getting queued over this visualization. Okay, let me just scroll this down. So you see all these things are now queued up, all the functions that needs to be executed. But at that time, both the queues are available and the event loop can pick which has the higher priority. So first function gets executed and it will pick up the render queue first. And then if the things are free, it will take the callbacks. In this sense, you are keeping your application responsive. At the same time, what you're trying to do is you're trying to sort of like give a slice of the execution in moment to your long running processes. So let's just conclude by saying that it's okay to understand the programming at an API level or a library level, but to really get the essence of the program, to really sort of like understand how things are and how this kind of all these things fit together to sort of like build a complex and asynchronous programming, you really need to get down to this level and sort of understand it from bottom up. And when you do that, you become those master chess players where you can think about the moves ahead of time. When you are actually writing the code, you can think about the implications that it might have. And you can sort of like code it in a fashion where you know, you can visualize how things will be at runtime. Make sense? I will open for questions if you have any now. Thank you. Hi, this is Raysha. One question on, you said the JavaScript runtime is different from the async the other calls. So if it is different, how the references are being passed between these two different environments? So the code is monolithic code. You have, what you have to understand is they share the same heap. They share all these things are same, but the runtime itself doesn't even have a clue that what set timeout is. Those things are implemented. Think about it as a library. You're building, you're adding one more library to your monolithic code only, but that library understand all these things. It has the implementation for the timers and Ajax calls and the DOM APIs. But the core of the runtime itself doesn't even have a clue. All it knows is that, given a function, I have to execute it. Now, when a set timeout is actually getting called in the call stack, it just says that, hey, who has set timeout implemented? It might be the user, it might be the library, it might be something else. Only job the JavaScript runtime has at that point of time is to execute it. That's all. All right. Are you good? Cool, thank you. Any other questions?