 Next session here, we'll discuss callbacks in JavaScript, which is a pattern style to execute functionality after you have done work. And sometimes it's being called a Hollywood principle that you don't call us, we call you. So the function calls you instead of you checking whether it's ready. And the reason we do this is that JavaScript callbacks are extremely common, most libraries use them, so you should be familiar with them, otherwise you'll be highly confused how to use external libraries. And the pattern is by itself pretty simple. So you have a function that does something, it's not important what it does. And it takes as a parameter a function. So you put in a function and that's the callback function. And it's called like that because at the very end of the function execution, you call this function, you call back. So whenever you call, in this case, do A, you have to provide some kind of function that is then at the end being called. And of course, you can add parameters to this, which then means that return values and so on can be passed back to you. And now the question is why do we do this? Because you know or you have seen that JavaScript has a return statement. So of course, as in other languages, you can have functions that return, return five or so on. So why do we need callbacks? And the reason is asynchronous execution. So in this case, this is a timeout example, the set timeout function in JavaScript basically waits, in this case, 500 milliseconds, and then calls a callback. And in between, nothing happens. And whenever JavaScript hits something that is asynchronous, it directly continues. So here we do set timeout, we call a function. And this function has asynchronous behavior. It doesn't do anything for 500 milliseconds. And that means JavaScript directly continues. So in this example, console.log is actually printed before console.log1 is printed. And here, this is irrelevant. We print two and one, this is not so important, but imagine that the first function does something that you depend on. So for example, this does an HTTP request that should give you back a return value, and then you want to log the return value. If you would do this here, your log statement would not print anything because the return value is not yet there. And this is why you need a callback function. So basically, you need something that automatically calls some code as soon as your function call has finished processing. And in this case, as I said, the timeout delays the execution by X milliseconds and then calls a callback function. So in this case, the output would be two and then one. Now, this is important. As I said, asynchronous behavior, timeout is maybe not the best example, but one thing that we do constantly in the internet is HTTP requests. So whenever we request an image, we call another web application. We expect some kind of response from a server. Then this takes a certain time and we don't know upfront how long this takes. Depending on how the server responds, this can take several seconds and can take milliseconds. So we don't know how long this takes. And this means we can't really wait for it. And in programming languages, there are a number of mechanisms to solve this. One of them is polling, that you basically have a loop that runs until there is a reply and every iteration it checks is the answer there, is the answer there. But that means while you do polling, you can't do anything else, you have to wait. You can also do message passing that something sends you a message, but this is typically quite complicated. And if we use callbacks, we can simply continue doing things and we know that as soon as, in this case, the HTTP response is there, we will get a call. So it's basically non-blocking. Other things in our script can continue running. The issue with this is that it's not so readable. So this is a real example where we use a function called to read a directory. So we read files, we iterate through the files. And for each file, we print out the size, for example. And the read directory function takes a callback. So you see here, it has a callback that contains either an error. If there is an error, we print something, an error message. If there's no error, then we can access the files. In this case, we iterate through all the files and this for each loop also has a callback. Whenever we get to the next file, the callback is called, then we use, for example, GM, which is another tool we do dot size. Again, we need a callback and so on. So these callbacks quickly become very nested and this is a small example, but this makes readability pretty hard. So for example, you see all the brackets, curly and regular brackets and semicolons down here and this is very easy to get lost in sometimes it's being referred to as callback hell. So this is the drawback of using all of these callbacks. And there are several ways of solving that. A simple one is to simply say you should not use all the inline functions. So what you see here is that we define the function within the function call. So it's an anonymous function. It does not have a name. One way is to say we should define them separately. So we should say here's a function that is called read callback. Here's a function that is called file callback and so on. And then later we simply use them. So for example, we simply say handle read, handle file and we use the different callback names whenever we use them and this way, at least when the callback is being put into the function parameter, we know roughly what it does. We get an impression of what it does and also the nesting becomes less problematic. Another option from ES6 on is promises, which has a bit of a more understandable structure but we don't go into them in this course either because they are a bit of an advanced concept. We might touch on them in the server side JavaScript lectures. Good, so this is the part of callbacks and next we go into the asynchronous execution in JavaScript. So I've motivated a little bit the time out and I've said here in this example that two is locked before one. This is only half of the truth but in reality there is a lot more behind how this is executed and we'll cover that next.