 Hello, this is Christian and welcome. In this video, I'll be talking about the asynchronous operations in JavaScript. So let's see what that's all about. And JavaScript is known as a single threaded language, right? What that means is that if you think about a train on a track, so the train is that thread, the main thread, we talk about the main thread in JavaScript. And the main thread or the thing, the main train is responsible for moving information from one place to another place. So if you are on this train and you want to move and go from one point A to point B, and that could be your first stop or your 10th stop, it doesn't matter, right? To get there, you are pretty much relied on this train here to get you there. So if there's anything that causes the train to stop along the way, then you out of luck. You may not reach there or you may reach at a later time. And when something blocks the train from moving forward, we say that is a blocking the thread, right? So it's quite common in JavaScript, by the way. And so you want to prevent that. Unfortunately, it doesn't have multi-threaded processes, like other languages like Java and C and C++ and so on. So these languages are multi-threaded. So again, the analogy here would be you have a lot of trains on multiple tracks and their jobs, of course, are to basically deliver those messages to what they're supposed to deliver. And because they're more trains, they can do it more efficiently. So to help JavaScript to kind of come back this or overcome this, JavaScript relies heavily on some very important web APIs that comes with the browsers. So remember that the engine in the browser is the JavaScript engine. But on the web browser itself, you have your own programs, right? It's a software itself that communicates directly with the server. So just put that into perspective. But anyways, these are some APIs that you've probably seen. Ajax is one of the very first APIs out there back in the mid-90s when it was created, I guess, to allow us to transfer or move data from one server to another server or from the server to the front end and back and forth. And there's some limitation to this. But it was very, very handy, very useful. And the reason why the X gets stuck in there is because of XML. And again, back at the time, XML was the de facto data format for use for transfer data. Nowadays, it's more on JSON, right? So that's why the name gets stuck in there. But anyways, you can see some of these different technologies you can use to kind of send some of this information out to a different track, if you will, so that the main track on your JavaScript program runs continuously. Okay, so we'll see some of these in action a little bit. And so Java runtime engine comes in every browser that you use. They have their own name, of course, like Google Chrome uses what's called a V8 engine, Firefox uses spider monkey, chakra for edge or IE and JavaScript core for Safari, opera uses caracan and so on. Okay, so each of these engines inside the JS engine, they have something kind of similar nature. We call a event loop. Okay, so this diagram is in no way is a complete specification for this event loop. I'm just showing you a very broad overview of what's really happening under the hood. So you can get a sense of understanding what's happening. And also how you understand how asynchronous works behind the scene. Right, so here we have, at the left side is the client, the client could be your browser, it could be another program that is communicating with your web application. And then this orange box here is the main thread, the JS runtime runs on this main thread. So every time you open a browser, you open the new tab, you have this thing going on continuously. And inside this JS runtime, we have a event loop. This is a loop that run continuously every cycle. It's also measured in one tick or sometimes called a one poll for polling. And so it receives information from the events, like these are like a click event, you know, mouse events, a keyboard events, or if you're on a mobile device would be like swipe and pinch and all those stuff, all those events, or even some other events from a data source to API, REST APIs. And when it receives those information, then depending on that type of event, at the event here has a single, we'll call a single stack or call stack. This call stack here tracks all the information is specifically function calls that you call. And it pushes those functions to your stack. And so which is why you see that when you run your code, if you have an error somewhere in your code, if you use the web browser tool to tell you, it will say Oh, it's here here. And so at this stack, you see the cost stack, it has a list of all your functions right in that order. And it tells you exactly where you started make the function call and it propagates to exactly what the error is. So it's through this call stack. So here if I call a function call f of x and inside f of x has some information that I would print to the console, it will add those to your call stack until these if it's a message that it needs to process right away, we'll process that, and then remove that from the stack. And then if there are no more information, and then you remove this function all the stack, and then goes with the next one, in that sequence in that order. So because whatever you pushes to the stack gets execute last, this is performing a this operational as a life or last in first out, right? The last in here at the top always get executed first. However, when you run into a function that will allow the event loop to move these data off to a mistake moving into a different track, these functions are very commonly used to the most important functions you'll be using are called set timeout and set interval, of course, and others as well called set media and so on. Or these are used to make we call asynchronous calls. Because now what this does is it will when it sees this function, it tells the browser or the engine that hey, move this information here, delay this until a later time. So if delay that information, and move it to another area or another truck, if you will, we call that the message queues. Okay, so over here is a queue. So a queue is different with stack, right? Queue means first and first out. So whichever receives the information first gets pumped out to the back to loop here. Okay, so it will delay that information. And while that's been delayed or being processed on a separate track, so this example here is like it's mimicking this multi-threading program, which JavaScript doesn't have. Again, this is a part of the browser, okay, it supports the system here. And so while this information is being pushed to the message queue, while it's doing its job over here, this event loop keeps pulling information keeps doing its task. Again, fetching data if there's any that's none and just keep waiting pulling until it receives this message back, and then send that off to the client. Okay, so this is kind of what's happening behind the scene here, all right? So let's go take another, see another diagram here. We'll set a code here first. For example, if I have a piece of JavaScript code on the left, this is a code you may, you know, write. On the right side is the result or the output of this code here. I'm just showing here whatever I put in the console law you will see on the right side. So the three statements I put in purple here are just a reference to tell you that these are, you know, put on a separate track, okay? So when you run this code from top to bottom at a very single tick, as you start a program, it starts a single tick, that's the first cycle. This is what happens, right? It runs out this entire little code on a single tick. Anything that's in purple here, it will push that off to a separate tick or a separate time and at least one tick behind, okay? In this case, I'm setting to a, this is a measured millisecond, so 2,000 milliseconds or two seconds, three and a half seconds, one more here for a one second, okay? So when you run down this code from sequence from top to bottom, this line here doesn't do anything. I just do an assignment. So we're not outputting that to the console. This line here is the gfx, it's a function call. We invoke a function down here, right, to print that gfx to the screen. So that runs right away. That's the first thing that happens. And then it runs to the next line, set timeout, it tells the engine, the browser, hey, send that off to the back, you know, do that at a later time. When do we do it? After this time runs out, okay? Remember that when you start this program, the time it starts right away, it goes at a constant time, it won't stop. So from time, from t0, all these things happens, okay? But this one here says, okay, run this after two seconds pass. Run this, then run this after three and a half seconds. And then this is nested inside the f of x, okay? So we'll get there. And then so this to a push to the next cycle, or beyond. And then it gets to this line. This one here runs right away. So you print that out. And then these are just functions. So they are doing nothing here. And then you're done here at the first tick. Then the second tick comes along, nothing happens, because now we're waiting for these timers here. So this is two seconds. This is sooner than this one. So this kind of run. And when that runs, when we reach a two second mark, it's going to call the f of x function. It goes down here. And we load this f of x to the console. So now when you start this function, the timer in here, it has its own internal timer. But again, this timer here is not a separate timer from the main timer. It still depends on the timer. So the overall timer here, even though I call the next time out here, it says 1000 second. This 1000 second here is still measured against the total time from the beginning here. So if you add this together, the 1000, 2000 plus the 1000 here is total 3000 or three seconds, because three seconds is still sooner than the three and a half seconds. So that means this is going to run first before this one does, even though this was run call first. Okay, so anyway, so the f of x will get invoked and it runs that out here. And then it runs the h of x because that is sooner than the three and a half. So you get that out to the f of x h of x here. And then finally, when we reach that three and a half seconds, then g of x runs, we get that out to the console. So you see the order here is complete auto order from your code here, because you're running on a separate track, separate time, I guess it's easier to think of it that way. Right. So this is a really important concept to understand asynchronous, when you make asynchronous calls. And because you're running code asynchronously, you prevent your JavaScript code from breaking or from blocking is the correct term when you use here. Okay, because they're not blocking, therefore your user will never see these information so they don't get distracted or get annoyed by your program being, you know, stalled. Right. So let's take a look at another diagram to see in visually. So here again, I have that same similar information here, one cycle is one tick or sometimes called a pole. So each of this block measures the constant time in milliseconds, I put here t zero and a thousand at 1000 millisecond, 2000 and 3000 and so on. So here is this time in seconds, you run continuously. In each second, you have a certain number of cycles or ticks that run through here. I put three here just to show you what it is, but really, there are more in that. Okay. So these are the functions I put them here on a separate track, they run on their own time. And then down here at the bottom is the actual code and the very first tick. So the first tick we run these because these are not, you know, put off on a delay, right. But when you make the set time off for f of x, this one here is put on a separate track is a wait until the two second time mark. So when these already ran, so these already ran and the existing memory. And then when we run this and this, we compare the two timers, well, f of x runs first because it reaches the two timer, 2000 time timer second first. So it runs f of x, it prints what it needs to be printed and inside that we have a nested timer to run each of x. So it will then call this function and this one runs, but it will wait until 1000 second, right from here on. So if you add this together, 2000 plus 1000, it will not execute until it reaches a 3000 second time mark. So at this point, this one runs already it executes. Well, you know, gfx is still waiting until the three and a half seconds. Okay, so this is can get really tricky. So if you were able to write asynchronous program is really complex to understand. And you can, you know, you can, you can really get a lot of headaches for doing that because you once you off the main thread, you have to find a way to come back to the main thread again. And that is one of the challenges that programers have to deal with when you write asynchronous code. But for us, we don't have to worry about that. We just basically use what we're given things like Ajax and fetch and, you know, the the other other methods that we can use their promises and things like that. So they already created for us to use. Okay, so I will stop here. I hope this is kind of give you a this kind of give you a overview of what is happening behind the scene when you run your code next time on using JavaScript. In the next video, I'll do a little demo to run this code so you can see what's really happening in live code. If you have any questions, please let me know.