[MUSIC PLAYING] SPEAKER 1: All right. Hello. Welcome back for Lecture One. And this week, we're going to be diving into more JavaScript and talking about ES6. So previous lecture, we talked about a few different topics, types being one. Who can name some types that we talked about last week? Anyone? AUDIENCE: String. SPEAKER 1: A string. AUDIENCE: A number. SPEAKER 1: A number. AUDIENCE: Null. SPEAKER 1: Null. AUDIENCE: Undefined. SPEAKER 1: Undefined. AUDIENCE: Object. SPEAKER 1: Object. And--- AUDIENCE: A symbol. SPEAKER 1: A symbol. And-- true or false. A boolean. Yeah. We talked about coercion, which was the process by which we change one type to other. Objects, of course, the non primitive type. Prototypal inheritance. Who can remember what prototype inheritance was? This was one of the complex topics from last week. Yeah. AUDIENCE: [INAUDIBLE] SPEAKER 1; Yeah, exactly. It's the process by which a more complex object can have methods and properties. We talked about scope which is basically how long a variable lives. How JavaScript gets executed. The global object, and I left you on a cliffhanger about closures. But before we dive into closures, I just want to give a little bit of more background on what these ES5, ES6, 2016, 2017, ESNext, what are those? So we talked a little bit last week on what ECMAScript was. ECMAScript is basically the spec for this language. It defines exactly what this language should do and how much of these functions behave. And JavaScript is actually an implementation of ECMAScript spec. And so which of these versions do environments support? Because every year, roughly, a new version comes out. So this is a little bit of a tricky question. It's kind of the bane of all JavaScript programmer's existence. Because we really don't know exactly what environment our code is going to be run in. And therefore, we don't really know exactly what is supported. And so, generally, what we do is the convention is to assume that the environment supports all of ES5. And so what are we supposed to do about these future language things that we can use? A big thing in JavaScript right now is what's called a transpiler. A transpiler is basically some code that goes from newer language features and actually makes it backwards compatible with the ES5 spec. So, basically, it takes all of your new language, any functions you are using that is defined by ES6, ES2016 and beyond, and actually turns them into code that's basically ES5 code. So some of these, the most popular one is probably Babble. But other ones you may have heard of are TypeScript, or CopyScript, etc. So which syntax should we use? Generally, what people do is they use the future syntax because either the language and the environments will catch up, or we just transpile things back to ES5. Does that makes sense to everybody? So in course, we will be using a lot of ES6 and beyond features. Cool. So going back to last week, we talked a bit about closures. At least I showed you exactly what the problem behind closures were. But to explain exactly what they are it's functions basically have access to variables that are around when functions are defined. And these functions actually retain the ability to use variables declared by a parent function even after that parent function has returned and possibly disappeared. And this is possible because of JavaScript scoping. And so let's see an example of how this works in action. So last week I talked about a possible bug with using closures. And let me just type that out really quick. So we had a function. And basically what it does is it creates a new array and pushes a bunch of functions to that array. And so let's do-- So does everybody following along what's going on here? So, basically, I'm creating a new empty array. I'm iterating through the numbers 0 through 5 and pushing on to a function to that array, which will cancel that log i. And then I'm going ahead and invoking that and storing the return as function array. And I'm going in and invoking the first one. And as we saw last week, even though we expected this to console.log0, it actually console logs 5. And so this week, we're going to go ahead and explain exactly why that happens. So before we do that, let's actually explore closures a little more deeply. And so what did we say a closure was? A closure is basically a function that has access to some variables that might have already left scope. So, basically, let's create a function-- OK. So what I just did here is I wrote a function that declares a variable called message. This message is just set to the string called hello. And then we create a new function that console logs a variable called message. And then return that function. And so at line 11, we invoke that. And so at line 12, what is the value of message here? Can anybody tell me? AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah. it's going to actually error. Because there's no such thing called message. Yet so let's just confirm that. We have an error because message is not defined. But now let's comment the out and run the code. And what we see is that say hello will actually console.log that message. And so let's dive a little bit more deeply into this. So we see that type of message at that point is undefined. And if we console.log say hello is is console logging a variable called message. And when we invoke that it prints hello. And so that there is a closure. Because we can see that the variable called message when say hello is invoked does not actually exist. Yet say hello still has access to this message up here. Because it was within scope when that function was created. And so that is what a closure is. Does that make sense to everybody? Yeah. AUDIENCE: [INAUDIBLE] SPEAKER 1: No. So the question was, would it make a difference if rather than having a const here we had a var or a let, and, no, it does not. Any other questions about this closure example? No. So and now let's go ahead and explore exactly why this bug exists. And so here what is the value of i? Can anybody tell me? Is it 4? Right here at line 13. Yeah. AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah, it's going to be undefined, right? Just because it's not actually within scope at that point. But as we talked about in the last example, because of closures, functions that are declared have access to their variables at the point of declaration. And so now right here what is the value of i? Can anybody tell me? AUDIENCE: Five. SPEAKER 1: It's going to be five, right? Because we iterated through the numbers 0 and 5. And by the time we got to 5, that was where I was left. And since it was declared with var, a var's lifecycle is basically until the function ends. And so line 8 right there, i has a value of 5. And so that's what gets wrapped up in the closure at line 5. And so when we invoke line 15, it now prints out 5. Does that make sense to everybody? It's a little bit strange. It's hard to wrap your head around. But does that kind of makes sense to why that's happening? So if we instead of using a var here, because var's lifecycle is from when it's declared until the end of its function, so line 11. What happens if we instead use a let? So what is the scope of a variable declared with the let keyword? Anybody remember from last lecture? AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah, exactly. It's until the end of the code block. And so this variable called i, it ends at line 6. And so if we tried to console.log i here, we get oh, it does not exist. And so i for each time this four loop runs, its scope is only from line four to line six. Therefore, this one, the closure will actually work as expected. So when we run this, it prints out a 0 as expected. Does that make sense to everybody? It is a little bit weird. And I'm about to show you an alternate way to create closures. But does this difference in scoping make sense to why it would print a five versus a zero? AUDIENCE: [INAUDIBLE] Sorry, can I ask a question. SPEAKER 1: Of course. AUDIENCE: [INAUDIBLE] SPEAKER 1: So the question was, what happens if we add another variable called i outside the four loop? Well, if we had one declared with a let or const key word, line five would error because we cannot create multiple let or const with the same names. If it were a var then it would get shadowed by this one and basically be overwritten. Any other questions with this example? AUDIENCE: [INAUDIBLE] SPEAKER 1: Ah, the question is what happens if we create a i variable [? outside. ?] So if we did let i equals sub number. Basically, the closure would wrap up the most specific variable. So since this variable is more specifically declared than the i outside, it would bind with this one. So if we ran this, it prints a 0. Cool. So let's look at another way to create a closure. So has anybody heard of immediately invoked function expression? Or the term iife? I-I-F-E, for short. So, basically, what an iife is is a function expression that gets invoked immediately. And so this also creates a closure. Has anybody seen this before or heard of it? AUDIENCE: [INAUDIBLE] SPEAKER 1: So the question was, is it like a nameless function? In a way, yes. It's a nameless function oftentimes. But it's a nameless function that gets invoked immediately. I'll show you what that looks like. And a benefit of using an iife is that it doesn't add or modify the global object. So we talked about last week how when you create variables or create functions, those functions are actually attached to the global object. But with iifes since they're just statements that are immediately invoked, they do not add to the global object. So let's take a look at what those look like. So say we had something like-- so we in the previous closure example, we defined this thing called a hello function, which was basically a function-- actually let's just copy that directly. So we defined a make hello function which had a message called hello which got wrapped in a closure by the say hello function. And we returned that function. And so as part of a global object we have this thing called make hello function. Which might not be ideal if we are running low on like names of functions that we can use. It's a way to basically create the same closure without actually creating a globally scoped function is an iife. So let's see what that looks like. So the goal is to have a say hello function which basically gets created by this make hello function with a variable called message that gets wrapped in a closure. And so another way to do that would be just saying const say hello is equal to this function. And we can make it an anonymous function. That's actually immediately invoke it. So does everybody see what happened here? So we went from this where it's make hello function. Which is declared as a function, which you can use anywhere in your code, and then at line 11, we go ahead and invoke that function which returns that function defined at line four which is a say hello function that wraps that var message in a closure. But here instead we don't create a function called make hello function, instead we declare an anonymous function, which just gets invoked immediately at line 9. And so we're left with that same exact function which is defined on line four. Where it's a function that console.log as a message which is defined by its parent function. But we don't actually have to create that global function name. Does that make sense to everybody? And so if we ran this we see the same exact thing. So why might an iife be useful? I'll just delete these. So say we want to have some class or something called a counter. And we want to keep track of some number that we can just keep incrementing, and we can get that number. But say we also did not want that number to be accessible to other people. How might we go about doing that? One way would be to use an iife. And so we can actually create that variable within a very limited function scope that is non-accessible globally. And so doing that real quick, we can create this thing called a counter which is a function where within here we create this variable called account. And we set it equal to zero. And then we can do something like return an object where if we do something like increment, it's actually a function which does count equals count plus 1. So it just increments that count. Or we can have a function called get which just returns. Or let's just console log the count. So this creates a function but instead we actually want that object back. So we can actually wrap that function in parentheses and immediately invoke it. And now we have an object that has an ink and a get function. And we can go ahead and invoke those. So we can do counter dot get, counter dot ink, counter dot get. And if we run that, we can see it gets the zero, increments it, and then prints out the one. But nowhere does any body have access to that variable at line 12. Because it's wrapped in that function that nobody can access. Because its scope is limited to lines 11 through 18. And the only things that have access to that variable are the return functions. And so that that count variable is not accessible in the global scope. Does that make sense to everybody? Do we see how that could be useful? Any questions? So how might we be able to use iifes to solve that closure problem from earlier? So let's copy that closure bug too. So we have this from earlier which is buggy. How might we use an iife to solve this problem? The goal is now to print 0. Any thoughts? So what if instead of pushing a function that consoles.logs i, we create a function that returns a function that console that logs i and pass in i. A little bit weird. So now we have a function that returns a function that console that log something called i. Now what we can do is we can immediately invoke that function with i. Do people see how that creates a closure by using an iife? So let's change a couple of these variable names so that it's easier to see. So we're pushing onto that array. The result of a function that returns a function that console.logs x. And what do we pass in as x, we pass in i. And so that creates a closure around that value of x Which is then accessible later on in the code. So if we go ahead and run this, we get that 0 as expected. Any questions on that? Is that a question? It is a little bit crazy. This is not something that you use every day. But this is something that it helps to know. Because you might see things like libraries get imported by using an iife. So that a lot of variables that they declare while creating a library don't pollute the global scope. All right. Moving on. So first class functions. So who knows what a first class function is? Has anybody heard this term before? So first class functions basically describes the way that language handles functions. And so in JavaScript, classes are first class citizens, people like to say. Or in other words, functions are treated the same way as any other value. And so as we learned last week that functions are really just objects. Everything that isn't a primitive is just an object. So it really makes sense that functions can be treated as other values. So functions can be assigned to variables. We've seen that when we do something like const say hello equals some anonymous function. They can be signed into array values, which we saw with this previous example where we're pushing onto the array anonymous functions. And they can be set as an object values, which we saw in our iife example when we returned an object that had an inc and a get function. They can also be passed as arguments to other functions. There's nothing stopping us from declaring a function which expects a function as an argument. And what that does is it allows-- oh, they can also be returned from functions as we saw earlier. In the previous example, we saw a function that returned another function. And so it allows the creation of higher order functions. So higher order function is basically any function that takes one or more functions as arguments or returns a function. And so some big examples of those are map, filter, and reduce. So does anybody have any questions on what a first class citizen means or a first class function? We have seen almost all of these bullets as examples in the past couple days. Cool. So has everybody heard of map, filter, and reduce? Has anybody not? OK. So basically these are three of the most famous higher order functions. What map does is it's an operation that can be done to an array. And what it does is it maps a particular function, any function to every single value in the array and then you get back an array where the values in the array are the result of passing the original values into some given function. What the heck does that mean? Well, it just happens to be that map is already built into the array class. So if we create an array like const x equals an array with 0, 1, 2, 3. And say we create some function called add 1. And takes in a number, let's actually do this in node. So say we had an array with 0, 1, 2, 3. And we had a function called add 1 which takes some number, and it returns the number plus 1. And so if we do add 1 to 1, what do we expect to be returned? Two. And how about if we did zero? We expect 1. 1 returns 2. 2 returns 3. 3 returns 4. And so if we were to map that function to each of the values in that array, we should expect to have an array that has 1, 2, 3, and 4. And so if we do x dot map, which is built into the array, if we passed in that function called add 1, it basically maps that function to each value in that array and returns the new one, the new value. And so as we expected 0, 1, 2, 3 returns 1, 2, 3, 4. Any questions on map? So what were the other two? Filter. So filter is basically another high order function where it expects a function and this function that you pass in can either return true or false. And basically what filter does is it retains the values that return true and gets rid of the values that return false. And say we have a function called is greater than 1. It takes a number, and it returns whether that number is greater than 1. It returns whether that number is greater than 1. So say we pass in is greater than 1, a number like 100, we expect it to be true. If we pass in a number like 1, we expect it to be false. And say we were to filter that original array 0, 1, 2, 3 by the function is greater than 1, what do we expect to get back? Is 0 greater than 1? No, so it shouldn't be included. Nor is 1. But 2, and 3 are. And so if we filter is by is greater than 1, we get 2 and 3 back. And the last high order function that we'll talk about it is called reduce. And basically what reduce does is it takes an array of multiple values and reduces it into a single value. And basically what that does is it takes a function that expects two arguments where the first argument is some accumulator basically. It marches down each value and returns that accumulator to the next value. And the second argument is whatever's next in that array. And so basically if we were to define a function called add which takes in two values and returns x plus y, we expect add 1 and 2 to return what? 3. And what would we expect 0, 1, 2, 3 to return? AUDIENCE: 6. SPEAKER 1: 6. So if we do x dot reduce and pass in add, we get back 6. Why is that? Because first it starts with zero. And basically it starts by invoking the first two arguments. So it has zero and one. It invokes add. So 0 plus 1 is 1. It passes 1 on as the first argument. And y is the next value in the array, so 2. So we have 1 plus 2 is 3. And so for the next iteration, x is 3, y's is this next value called 3. It returns 6. And since that's every value in the array, it returns 6. Does that make sense? So those are the three higher order functions that we're going to talk about. And let's actually implement those. So in four higher order functions, let's go ahead and declare some higher order functions of ourselves. So let's do-- does anybody have a preference if they want to do map, filter, or reduce? Let's do map. All right. So let's declare a function called map. And let's take two arguments. First, is the array that we want to map over, and the second is some function that we want to invoke to every value on the array. So can anybody give me a strategy on how we might go about implementing this? So first we're going to want to create a brand new array. And then at the very end, we're going to want to return that. Now what do we want to do before we return? AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah. So the comment was first, we should check if the array is an array and the function is a function. I completely agree. But let's just assume that for now. So what does map do? It takes every value in an array runs through some function, and returns another array with the return values. So who wants to give me a strategy? Yeah. AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah. So some sort of four loop that will grab that value in the array and apply that function. Cool. So we can do four let's use let i equal zero. i is less than however many values that are in the array. And that's do that the value just be array i. And then what we want to do is new array push a value onto that new array. And what do we want to push on it? The result of running that function on that value. Does that make sense? Cool. So this would be absolutely correct. Unless somebody sees a bug. Shall we test it? So we want to map over x, add 1, and we expect to see 1,2, 3,4. And we do. Nice. And so one handy built in function to all arrays is this thing called a for each loop. So we could actually clean up our code by using a for each loop. And so we could do the original array dot for each. And what that does is it's a higher order function itself that allows us to pass it a function. And it will invoke that function on each of the values. So it's basically like map but instead of returning a new array with those values, it just invokes that function on those values without taking the return function and putting it in an array. And so we can say for each value here we just push onto that new array the value after we run it through that function. Does that make sense? Cool. Any questions on the implementation of map? Any questions on functions as first class citizens? Do you think it would help if we implemented filter or reduce? Or are we good here? No? OK. Moving on. Cool. So you may have heard these terms thrown around when dealing with JavaScript, things like synchronous, asynchronous, single threaded. So what is JavaScript? JavaScript is actually single threaded synchronous language. And so since a synchronous is a function that takes a really long time to run will cause a page to become unresponsive. And we can actually demonstrate this. We can do this right now by opening up our dev tools. And I'm going to actually cause this website to stall out. So we can write a function called hang. And let's say for some amount of seconds. And basically what this hang does-- oops. Let's override that function called hang. And what it does is we can say const done at is some time in the future. So date dot now which gets us to the current time plus however many seconds we want times 1,000. Because date dot now returns milliseconds. And so now we have some value called done at which is the time that we're going to be done. We can do while date dot now is less than the time that we're done. Just do nothing. And so now everything is good. As you can see, we can move back and forth in the slide. But if I did hang for 10 seconds, we're stuck for another 10 seconds until the page is done with that [? what ?] loop. Well. Does that make sense? And this is because JavaScript is single threaded and synchronous. And so since this while loop was running for 10 seconds, it was just doing while this is true don't do anything. It's just going through that while loop, it locks up the entire page. Yeah. AUDIENCE: [INAUDIBLE] SPEAKER 1: I believe so. So the question is if we did something like while true, would it just lock up the page permanently? I believe so. Unless the browser protects against that. And I don't want to try because it will take down the presentation. But as we just demonstrated, since JavaScript is single threaded and synchronous, while that while loop was happening, we couldn't do anything at all on that whole website. Which you could take advantage of if you wanted to like have some malicious web site which just does some while loop and locks up somebody's computer. But JavaScript also has some functions that act asynchronously. And so let's take a look at some of those functions. So one of those functions is called set time out. And we'll look into it a little bit more in detail. But let me just show you how that works. So let's do a function call a print 3 or print 1. And what that does is it consoles logs 1. And let's it have a print 2. And a print 3. And then if we invoked print 1, print 2, print 3, what would we expect to see? 1,2, 3. But say we use this thing called set timeout which is basically an asynchronous function. So say rather than printing 1, we did set time out on print 1 to be a second, a 1,000 milliseconds, or did set time out on print 2 with a time out of zero seconds. And then print 3 knowing nothing about set time out other than it set some time out before running a function. What do we expect to be console logged? So what order do we expect these to print? Anybody care to guess? 3, 2, 1. Why do you say that? AUDIENCE: [INAUDIBLE] SPEAKER 1: OK, so 2, 3, 1 is the other guess. So let's actually just run this. And we see 3,2,1 even though set time out for print 2 is zero. So let's dive a little bit more into how this works. We we'll dive a little more into this how this works in a couple more slides. But that's just a teaser at asynchronous functions. So how exactly can a language be both synchronous and asynchronous. In order to explain that, we have to explain these concepts called executions stack, browser API's, function queue, and event loop. So let's dive deeply into what an execution stack is. Has anybody heard the term stack or execution stack? So functions that get invoked by other functions get added to this thing called a call stack. And we'll discuss a little bit about more what that is in a second. And when functions complete, they are removed from the stack and frames below continue executing. So does anybody or everybody know what a stack is? So a stack is one of those data structures that you may have seen in CS 50. And the example that we give for a stack is something like a deck of cards or a stack of lunch trays where when you add things to the stack, they appear on the top. And so when you want to grab the next thing, whatever you grab first is the most recent thing that you've put onto the stack. So if you imagine a deck of cards, say you have cards called 5, 4, 3, 2, 1, and you place 5, 4, 3, 2, and 1 on the stack, the first thing that you get back is 1 and then 2, 3, 4, 5. As opposed to something like a queue where it's like a line of people where the first person in line is the first person who comes out. And so let's explore what stacks are. Actually I'll show you in code first, and then I'll draw it. So say we had a function called a. That just does console that log. i, a function called b, that just calls a, and a function called c that just calls b. And then we invoked c. So can everybody imagine in their head exactly what's going to happen? So c is going to get invoked which calls b. b is going to get invoked [INAUDIBLE] a, and a is going to console.log [? high. ?] And so as you can imagine, the JavaScript interpreter knows exactly where which function gets added next. Actually a better example would be something like we can use or add 1 function from above from earlier. All right here's a little bit of a better example. So when we invoke c, c is going to console log, get numb plus get numb. And so what is the value of get numb? So when you invoke the first get numb, it returns add 1 of 10. And so it calls add 1, passes in 10, add 1 returns that original number plus 1. So it returns 11. Which returns to here, which gets returned to here. And so somehow JavaScript has to know that 11 is what get numb evaluates to. And then it does it again. And so as you expect, this would return a number [INAUDIBLE] console that log a number called 22. But let's actually go through exactly how that works in drawing. So we have a function called add numb or add 1. Which expects some numb. We have a function called get numb. And we have a function called c. And what c does is it gets two numbs and adds them. And what add 1 does is-- or what get numb does is it gets the value of add 1 of 10 and returns it. So imagine we have this mythical call stack. Which is basically the way that JavaScript knows what's going on. And so first, we invoke c. And so c gets added onto this stack. And so it's basically JavaScript remembering like, oh, he called the c function. And what does the c function does? Well, it returns get numb plus get numb. And so in order to find out what get numb is for the first time, we have to add get numb. We have to evaluate that. And so what is the value of get numb? Well, we have to figure out what add one of ten is. And so we need to evaluate that. And so JavaScript now knows and is keeping track that we have to evaluate this thing called add 1, and once we get it, it gets passed to this thing called get numb, and once we have that value, it gets passed to c. And so this returns 10 or 11. So it returns 11 to get numb. 11 just returns that to c. And then what happens in c? Well, it needs to find get numb plus get numb. So it has to evaluate get numb again. So get numb gets added to that stack. And how does get numb evaluate? Well, it needs to evaluate get 1 or add 1. And so that evaluates. And after it evaluates, it just gets erased from the stack because it's done. And then when get numb evaluates, that also gets erased from the stack. And then c console logs 22. And then c gets erased from the stack. Because that has finished executing. Does that make sense to everyone? Yeah. AUDIENCE: [INAUDIBLE] like if one of the stacks creates a [INAUDIBLE] do those variables [INAUDIBLE]?? SPEAKER 1: So the question is what happens if one of those functions creates a closure? Does it still disappear from the stack? The answer is yes with an asterisk. So as long as nothing else needs to remember all of those variables and stacks. So if these functions don't create other closures then they'll just be erased. And you can just think of it as being erased from memory because that's really something that the engine itself handles. And you really don't have to worry about memory and stuff. But you can just think of it as it just gets erased from the stack and from memory if no closure is left around. But great question. Any other questions? Does this call stack makes sense to everybody? Great. And so a quick demo of just showing that JavaScript does indeed keep track of this call stack is what happens if an error is found. So if one of these functions ends up creating an error, in this case add 1, and we run this, it says, oh, no, an error which is the error that we created. And it says add 1 which was called by get numb which was called by c. And so JavaScript does indeed keep track of this call stack. And you can see when an error gets thrown, it basically dumps the call stack to the console. Does that make sense to everybody? Any questions on call stack, execution stack? Great. And so now going back to asynchronous JavaScript. So how exactly does this thing called set time out work? How does it not just immediately get invoked? How does any asynchronous things work. And in order to understand that, you first need to understand execution stack. And then I can talk you through exactly how things get handled in terms of browser API's, function queue, and event loop. Let's go ahead and draw that on the board as well. So this thing here we can call the stack. And this is basically exactly the same stack that we were talking about before. Over here we can call this API's. Basically these are functions that you can call that are not directly built into JavaScript but might get run in the browser. We have this thing we can draw down here called the function queue. And we have this thing called the event loop. So basically we talked in depth about how that stack worked. But we have not mentioned API's, event loop, or function queue. So basically what API's are these things like set time out or fetch or any of these other asynchronous functions which get run and handled by the browser but not necessarily by JavaScript itself. And so say we had something-- does everybody remember the example from before with print 1, 2, and 3? Let me remind you of the code real quick. So we have print 1, print 2, and print 3, are our three functions that we defined. And we set time out print 1 to 1 second, set time out print 2 to zero seconds, and then print 3 immediately. And so when this file gets executed, three things happen. First we call print 1. But set time out for 1 second. Then we do the same thing with print 2 for zero seconds, and then we'd call print 3. And so basically set time out of print 1 for 1,000 seconds gets tossed on the stack here. And set time out is actually one of those asynchronous functions that gets handled by the browser. And so that gets tossed over here. And so that's print 1 in one second. And so the browser actually is the thing that handles keeping track of the seconds until print 1 should get executed. And then the function queue says, OK, I executed that line of code, I'm done. Next is set time out of print 2 for 0 seconds which gets thrown on here, that gets evaluated, and that's handled by the browser as well since it's a set time out call. So this gets print 2 with a time out of zero seconds. And then the next line of code in the file was print 3 which immediately gets tossed on the queue or on the stack, and it consoles that logs 3. And so 3 gets consoled out logged. And then the state of the world is basically this. Because all of this happened in very, very quickly. Is everybody with me so far? And so now the browser says, hey, it's been zero seconds. It's time to call print 2. And so this gets put in the function queue. And so as we alluded to earlier a queue is basically a line where the first things that get added are the first things that come out. And so it says print 2 is ready. And that gets erased from here. And so now the state of the world is this. There is nothing on the stack because that file has finished executing. It did set time out of print 1 1 second. It did set time out of print two for zero seconds. And it did set print 3 which immediately console log 3. And so now the state of the world is this. There's nothing on the stack. There is one thing in the function queue. And there's one thing over there called print 1, and the browser is keeping track of the time. And so there's this thing called the event loop which it just constantly checking. First, is there anything on the stack? If there's something in the stack, just keep doing what you're doing. Finish the stack. But once the stack gets emptied, it says hey, is there anything in the queue that's ready to go onto the stack? And now there is. The stack is empty. And there's something on the queue. Until the event loop says, hey, let's move this into the stack. And so the event loop takes care of moving print two onto the stack and erases it from the queue. So now the state of the world is this. There's something on the stack called print two. Function two is empty, and the browser is still keeping track of when it should print 1. And this is basically still 1,000 milliseconds. So now it's good, what happens? Since there is something on the stack that always gets the highest priority, since we know JavaScript is synchronous, it's just going to execute everything on the stack before even looking anywhere else. And so since there's something on the stack called print 2, it executes that. What does it do? It prints out 2. And then says, OK, I'm now done with the stack. And so now this is the state of the world. There's something over there being tracked by the browser called print 1. It still has 1,000 milliseconds or so on the clock. There's nothing in the stack. And there's nothing in the queue. And the event loop is saying, oh, there's nothing for me to do. So now what happens? Well, basically nothing for a whole second. So basically this timer runs down. And as soon as this hits zero, can somebody tell me what happens? AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah. So print 1 moves to the queue. So as soon as this hits 0, this gets moved down to here. So now we have print 1. This gets erased. And now what happens? AUDIENCE: [INAUDIBLE] SPEAKER 1: Exactly. The event loop says, hey, the stack is empty. But there's something on the queue, so let me move that up to the queue or the stack I mean. Move the thing from the queue to the stack. And so now print 1 is here. Gets erased from the queue. And then what happens? Print 1. And then the stack is cleared. And now we're done. There's nothing left being tracked by the APIs. There's nothing left in the stack, and there's nothing in the queue. And so what happens at the very end, well, we print 3,2,1. Does that make sense to everybody? Yeah. AUDIENCE: [INAUDIBLE] whereas everything that is on the [INAUDIBLE] which it appeared there? SPEAKER 1: Yes, exactly. So the question was about ordering, and how is order affected when things are on the stack? Queue and the APIs. Over there. And the answer is exactly as you said. Everything in the stack has a definite order. Things at the top get executed before things on the bottom. And same things at the queue. Things get queued up. And as soon as the stack is empty, whatever's next in the queue is guaranteed to be in the next thing on the stack. And if that thing calls other functions, the stack will grow and shrink before even grabbing another function from the queue. And then things in the APIs over here, these you have no real guarantees on what order they're going to return in. And so that's what the asynchronous or the concurrency of model of JavaScript is. It is basically these APIs are handled by the browser. And they will basically let the rest of the JavaScript know when they are done by pushing things onto that function queue. And then as soon as they're on the function queue, then you have a guaranteed order when they're going to get put onto the stack. Does that make sense? AUDIENCE: So if you set time out on three different things for the same amount of time, is there a guaranteed order? SPEAKER 1: So the question is if you set time out three different things is there a guarantee in order? I believe so. So if you do set time out of print 1, 0, set time out of print 2, 0, set time out of print 3, 0, I believe you're guaranteed to print out 1,2,3. But the caveat is that it depends on the implementation of the API. So it really depends on the browser you're using. But I believe browsers will have that guarantee. Any other questions? Yeah. AUDIENCE: For the event loop, you said it starts with [INAUDIBLE] So like that's just whenever [INAUDIBLE] SPEAKER 1: Exactly. So what the event loop does is it basically checks when the stack is empty. It moves something from the queue to the stack. And that's all it does. Is it's just constantly checking, hey, is the stack empty? If not, then I'll wait. Is the stack empty? Oh, now it is. Is there anything on the queue? Oh, there is. So let me move it to the stack. Yeah. AUDIENCE: Is there a limit to the queue? SPEAKER 1: Is there a limit to the queue? AUDIENCE: A realistic limit? SPEAKER 1: Is there a realistic limit to the queue? No. The limit to the queue is basically what can be held in memory. And so what happens if we run out of memory? Let's have an example that does that. So this won't actually overflow the queue. But this one will overflow the stack. So we have a function called recurse. And recurse let's console that log, recursion, and then return recurse. So what do we expect to happen here? Yeah. So recurse is going to console long recursion. And in return, the return value of recurse. What's the return value of resurce? Well, it's recurse is return value. And so we're going to keep going down that rabbit hole until we run out of stack. So if we run this, oh, maximum call size exceeded. Because if we scroll-- I'm actually scrolling. There are a lot of these, a lot of them. So that's what happens when we run out of stack size. Cool. Any questions about the asynchronous JavaScript? So what are some examples of asynchronous functions in JavaScript? Well, we saw set time out. I alluded to this thing called fetch which is the way of fetching network requests. JQuery, if you've ever used it, it has a lot of asynchronous functions for fetching things like Ajax. EXML HTTP request which is built into the browsers for fetching things, things like database calls. Anything really that relies on something other than the JavaScript is going to be asynchronous. Cool. So what happens if we want something, say we have some asynchronous call, and we want to do something with the return value of that call. How might we do that? Well, we could just wait for it to come back, but that wouldn't be really great would it? If say we have some web site which is what's shown is relying on some database call, we don't want to like lock up the entire web site until that database call comes back, right? That wouldn't be very good for the user. The analogy there would be say you wanted to hang out with your friend, and you call him, and you say, hey, let's hang out, and he says, oh, I'm at work, I'll be done in five hours. You don't say, OK, and then just sit there for five hours, right? You go ahead and do other stuff. And then five hours later, you say, oh, my friend is done with work, now let's go do something. And so that's exactly how JavaScript's concurrency model or asynchronous model works, is this thing called callbacks. Callbacks are the way that you control flow with asynchronous calls. Or in other word, you execute some function as soon as some asynchronous call returns a value. And what that means is the program doesn't have to halt and wait for that values. You don't just sit there until your friend is done with work. You go do other stuff, and when he's done then you say, OK, now let's go hang out or something. Does that make sense? You want to see this in action? So let's have this function which takes a callback. Well, first let's just do something and then-- so function do something takes a callback and console logs the result of invoking that callback on 1. So what type is that call back? It must be a function, right? If it's getting invoked. And so do something is basically a higher order function like we discussed earlier, which takes as an argument some function and will invoke it with 1. And so say we did do something, let's not even console log. Let's just invoke it. And we pass it into do something console dot log. What would happen? Well, we passed in this function called console dot log to do something. And then at line 2, we invoke console dot log with 1. And so we expect this to console log 1. But say do something was actually an asynchronous call. Say rather than invoking the callback on 1 immediately, it did set time out for some number of time, one second. And set time out takes a function that immediately invokes. So we'll just create an anonymous function that invokes callback on 1 in one second. Now it's not do something, but rather it's do something async. Now what do we expect to happen? Well, one second later, it console logs 1. And so this is an example of a callback. So we have some function that does something asynchronously. In this case, it returns 1 basically a second later. I mean how do we control what we are going to do with that value soon as it returns? Well, we just pass in a function that says, hey, we know that this asynchronous function is going to return some value eventually. And so let's just pass it a function to handle what we're going to do with that value. And so with do something async, what we're doing is we're passing in a function called console dot log, and what we do is we console dot log the return value of the async function whenever it decides to return. And so for things like network requests where we don't know exactly how long it's going to return, what we do is we pass in a function that handles the eventual return value. And so as soon as that network request comes back, then we have the function that will say, oh, I know what I'm supposed to do with that network request let me do it. Does that pattern make sense? Any questions on callbacks? Great. Let's look at an example with callbacks. A real life example taken from some code that I've actually written. So from personal project of mine, I have this function called log in. And what log in does is it has a whole bunch of asynchronous functions. So log in takes a request and a result and some callback. And so what we're doing basically is we're looking for the user by their email. This is an asynchronous function. And we're passing in a callback with it. And this callback takes in an error, if an error occurs, and the user, if the user exists. And if there's an error, we return this original callback. It says, hey, there's an error. Let me handle like that. Otherwise, there's a user that came back. And so let's do this user dot compare password which is asynchronous. And so we need to pass in a callback function with that. And that callback function is here. And so either there is an error or it matches. If there's an error, handle that error. If there's not a match, say, oh, incorrect password. Otherwise, create this token and then sign that token which is another asynchronous function. It takes a callback which expects and error and a token. If there's an error we handle the error. Otherwise, we handle that token, save that user, which is another asynchronous function. And so the callback takes the error. If there's an error, handle it. Otherwise, return. And now we're waiting nested into this what is known as a technical term callback hell. Basically callback with a callback with a callback with a callback and another callback. And so that there is called callback hell. We see this that kind of looks like a Christmas tree. If you've ever seen there are some pictures online of callback hell where it's like 10 20 iterations deep. And you see basically this Christmas tree of code. And that there is the downside of callbacks within callbacks. And we're going to take a short break now. And after the break, we'll look at some ways of combating this callback hell. All right, welcome back. Before the break, we were showing this function that I wrote on a personal project of mine demonstrating this thing that we called call back hell. That is callbacks within callbacks within callbacks recursively. Which gets a little bit messy and hard to read. And I alluded to this thing that we could use to alleviate callback hell which is promises. So who here has heard of a promise before? Who here has heard of a promise in real life before? Hopefully, everybody. So what's a promise in real life? It's basically you telling somebody that you're going to do something eventually, and they can just have your word that you are going to do it eventually, right? And so that kind of seems like the asynchronous model of JavaScript. Whereby you basically get some sort of promise that something is eventually going to happen. And so JavaScript also has this object called a Promise, capital P, whereby you can alleviate callback hell by writing code that assumes that a value is going to be returned eventually with the access function. And a big upside about Promises is that you only need a single error handler. And so we saw with the callbacks' example over here, we see line 15, if there's an error return this. If line 8, if there's an error handle it, line 5, if there's an error handle it. Like 19, if there's an error, handle it. And with Promises what we have-- a big advantage of promises is that we don't have to handle the error within every single callback. We can just do it once and be done. So let's go ahead, and let me show you how Promises work. So say we have some function that returns a Promise. One of those functions is called fetch. And we'll talk about fetch in depth in a few weeks. But just take my word for now that fetch returns a Promise. So we could do something like fetch some URL. And then we know that fetch returns a Promise. And eventually it's going to return to us this URL. So we can start to do is write a function that expects the response to come back and start handling it already. And the way you would do this with a promise is this thing called dot then which takes a callback itself. So we could have a callback that takes the response and does something with it. If we want it to then handle that later, we can chain a dot then that takes whatever, some JSON maybe, and does something with that. And maybe if we wanted to do something with that JSON dot later, we can do dot then again. Do something with that. So on. And we can just keep chaining these thens as long as we want. And so this is basically the same as putting a callback within a callback within a callback. But as you see, we don't keep creating this Christmas tree of callbacks. Rather we just chain a new dot then. And we don't actually have to worry about handling an error here. Instead, what we can do is a dot catch. And this catch function down here will actually handle any errors that get thrown in any of the preceding then statements. And so we could handle the error here. And we would not actually have to do it in any of the then statements over here. And so something that you might see, we'll discuss this in later lectures. But you might see something like return res dot JSON. Which is basically saying extract the JSON out of this result. And here you might be doing something like return only the important parts of the data maybe. We could do like important data is JSON dot important. And so on. And maybe down here we eventually want to just console dot log it. And so this would be an example of using a Promise rather than using callbacks within callbacks within callbacks. And so let's actually refactor my old authentication code to use these Promises. So here we have a bunch of callbacks. And one thing that we know is that we don't actually have to handle any of the errors. So first thing that we do is we're going to do user dot find 1. So basically this. And so before let me show you a before and after. Before we had this function called user dot find 1 which takes in basically the query that we're looking for as well as the callback function. But rather than passing in a callback function, we can actually, since this does return a Promise, we can do a dot then that has a callback function which expects a user. And so we've started to start refactor line 5 here. So rather than passing a callback function that takes an error in the user, we just do a dot then that handles the user. And how do we handle the error? Well, we just have a dot catch dot error. And what have we been doing with that? Well, if there's an error, we just return callback error. So we can do that in the [? catch lock ?] there. And now we're done handling errors for the rest of the Promise. And so we can get rid of line 11. You can get rid of line 17. And we can get rid of line 20. Now we can get rid of 10 since we already refactored it out. Then what do we do with that user? Well, you can cut and paste that into there. So we want to compare the password. And compare password takes in a password as well as a callback. And so let's go ahead and return that. And then handle that callback with another then instead. And so rather than having a callback that expects an error and is a match, we can just only handle that is match case. And so what do we do if there's not a match? Then we want to tell them there's an incorrect password in return. Otherwise, we want to take what the payload is and return this new [? jot ?] sign Promise. So let's do this. Copy and paste this. Get rid of that callback which expects an error and a token. And, instead, return that, and handle that in another then. What did we expect? We expected a token. And what do we do? We do this. And user dot save, it looks like it takes another callback which is only looking for the error. So we could return user dot save. And then, finally, do that. And then we get to get rid of all these closing curly brackets. And that there is our new login function with Promises rather than callbacks. Did that refactor make sense to everybody? And does this Promise structure look nicer than the callback structure? This is something we're going to go into a lot more depth in when we talk about data in a few weeks. But do Promises in general make sense to people? Yeah. AUDIENCE: [INAUDIBLE] SPEAKER 1: So, yeah the question is how does the catch function know when to get invoked basically? And basically this is all so user dot find 1 dot then dot then dot catch is all one big basically Promise handling chain. And promises, which are built in, know exactly what to do when an error is found. So if an error is found, it'll just march down that chain until it finds a catch statement. And then it will invoke that callback with that error object. AUDIENCE: But that's not [INAUDIBLE] SPEAKER 1: And it stops future thens from happening. Any questions on promises? Again, we'll dive more deeply into them in coming weeks. Yeah. AUDIENCE: So a Promise is a good solution for all the bad stuff what comes with callbacks where what is the trade off? What can you do with this that [INAUDIBLE] you still have to go back to callbacks [INAUDIBLE]? SPEAKER 1: So the question is what's the trade off between callbacks and Promises? And what, if anything, do we lose when using Promises over callbacks? The answer is not really much. Most things are migrating from the callbacks of the past to now Promises. But Promises were something that were introduced fairly recently to JavaScript. Which is the reason that callbacks still exist a lot in legacy code. And so what is the future? So right now, Promises are very popular. But there's a new way of handling asynchronous things that's coming in the future. So there's this thing called AsyncAwait which is actually introduced in ES 2017 which is the next, next maybe. So ES 2017 has been finalized. But it's still not adopted by everything. But AsyncAwait is included in that ES 2017 spec. And it allows people to write async code as if it were actually synchronous. And so we're not going to dive too deeply into this. But I thought I could just show you quickly a refactor of what we've done so far to use this AsyncAwait rather than the Promise syntax. So right now log in is a big Promise chain. And if we refactored it using this new AsyncAwait syntax, we can actually make it look very synchronous. So first thing that we need to do is add an async keyword to the function which is letting the JavaScript interpreter know, hey, this function is async which means handle it appropriately. Which is basically what it does is allows us to use this other key word called await which will functionally just wait for a value to come back before continuing the code. But it does this asynchronously behind the hood. So basically what user dot find 1 dot then function user is doing is waiting for a user dot find 1 to return with some value, which is going to be that user. And so if we were writing synchronous code, we might do something like const user equals the value of user dot find 1. And if we were using AsyncAwait syntax, we could basically do that by saying const user is user dot find 1. But we know that user dot find 1 is actually an asynchronous function. So we actually have to just wait for that response to come back. And so if we use that await keyword, it's basically saying, hey, wait for that result to come back. But don't actually just like stop and wait, just wait behind the scenes asynchronously. And so what might we want to do, well, then next we want to do user dot compare password which gives us this thing called is match, and so if we're doing this synchronously, we might do something like const is match equals await user dot compare password. body.password. Then this is basically asynchronous code, right? We can do if it's a match, do this and return. Otherwise, create this payload. And then sign dot jot which will give us a token back. But since this is an asynchronous function, we have to use that await key word. Then what? Now we have the token, so let's do these things. And rather than returning user dot save, which is what we would do in a Promise, well, we just want to make sure that it succeeded. So we can do const success equals that. And as long as that works, then we can go ahead and do res dot JSON with that token. And now we're basically done. What's one thing that we haven't handled? The case where one of these things errors. And so we haven't talked about this before, but JavaScript actually has this thing called try catch which allows us to try to do some code. And if an error happens, intercept that error and handle it in code rather than delegating to the browser's error handling. And so what we can do is we can actually wrap all of this logic in a tri lock and catch any errors and handle those appropriately. Which is basically by invoking the callback that's passed into this login function with the error. We're done with error handling, and we can just style this appropriately. And so now with this new AsyncAwait syntax, we can write async functions in a more synchronous manner. But everything behind the hoods is still running asynchronously. Oops. One thing we forgot to do is await this value. Any questions on this syntax? Again, this is something that will dive more deeply into as soon as we get into actual data handling in the future. As a random poll, who prefers callbacks over everything we've seen today? Who prefers Promises? And who prefers AsyncAwait? About 50-50 actually. Cool. Noted. And people online do just drop something and slack, and I will take your votes into account. Cool. So let's pivot a little bit from asynchronous actions and talk about this. And by this, I literally mean this. So who here has seen this keyword called this in JavaScript before? Who here seen this in other languages? So this in JavaScript is slightly different than other languages sometimes in confusing manners. But, hopefully, by the end of this lecture, it will not be confusing. So this basically refers to an object that's is set at the creation of a new execution context or in other words a function invocation in other words another stack frame on that stack that we drew earlier today. And in the global execution contests, or basically the window console or the node REPL or the function that gets invoked in node, it refers to a global object. And if a function is called as a method of an object, or in other words, a method is basically a term for a key value pair in an object where the value is a function. That key is considered a method. So if a function is called as a method of an object, this is bound to that object that function is called on. So what the heck does that mean? Well, so let's just demonstrate in node. If we just type this, we get back that big global object. In the browser console, if we type this, we get back that window. So as we discussed last week, we saw that window was indeed the global object in the scope of the browser console. And how might we write something such that this gets bound to other objects? So let's write 12 this. Cool. And so I mentioned that if a function is called as a method of an object, this, is the key word this, gets bound to the method that the functions is called on, or the object that the method is called on. So let's just create some objects. So let's do const person is somebody with a name. And let's have a function called greet. So in line 3, I'm using this thing called this dot name. And this is part of a function which is defined as a method on this object. Remember, a method is just a key where the value is a function. And so in this case, person dot greet is considered a method because greet is this function. And so if we call person dot greet, this gets bound to person. And so this dot name becomes the value of person dot name, which in this case is Jordan. So if you were to run this, we see Jordan [? Gifts. ?] Printed. Let's make this more of a greet by doing hello. Then we see hello, Jordan. But what happens if we want to do something like this? What might we expect to happen in this case? So we declare this global const called greet. Global meaning it's outside the other object. And we set it equal to person dot greet. And so, basically, greet right now is a function that console dot logs hello this dot name. So what is this in that case? So first we have to find where is this function getting invoked? That's at line 10, right? It gets defined at line 8, but it gets invoked at line 10. And so what is the value of this here? AUDIENCE: It's a global object? SPEAKER 1: Yeah. It's a global object. And so what is the value of this dot name? AUDIENCE: [INAUDIBLE] SPEAKER 1: So yeah, name is not actually a key on that global object. And so if we try to de-reference a key that doesn't exist on an object, we get undefined. And so if we do this, we're going to get hello undefined. Does that make sense? But what if we were to create some other object called student? Let's call it friend. I mean a friend has a different name. But their name is David. And how if we did something like friend dot greet equals person dot greet. So now what do you expect to happen? So where does greet in this case get invoked? Line 14. And what is it getting invoked on? Right now it's a method of another object, right? And so what I object is that? Well, that's friend. And so what does this get bound to? It gets bound to friend. And so what is friend dot name? In this case, it should be David. So let's try running this. And we get hello, David. Does this make sense? So now-- Yeah. AUDIENCE: [INAUDIBLE] really explicit and instead of saying this you could have just referenced to context as you are typing you know what the developing context is. So is this should it be thought of just a useful short cut or? SPEAKER 1: So the question is for the camera, is this should it be thought of as some sort of useful shortcut? In a way, yes. It's a way of using a variable. And we don't yet know exactly what that variable is going to be bound to. Because in the case of person, we know that this dot name is going to be equal to that person. But that's not always the case, right? As we saw if we take this greet method on person and assign it to friend, this dot name is not person dot name. In that case, it's going to be friend dot name. And so it's kind of a way of using a value that we don't yet know what it's going to be until we go ahead and invoke that function. And when we start handling events and stuff and react and stuff like that, we will see or even react components and stuff like that, which is coming in the next lecture, we'll start to see exactly why this, a key word called this, is useful. Cool. And now let's do a challenge together. Let's try to get line 18 to greet somebody. How might we go about doing that? So what does this greet function do? This greet function just does console.log hello to this dot name. And so we need to figure out some sort of way that when line 18 gets invoked, that this dot name is bound to some variable that we want. So there are a few different ways to do this. Let's see if we can figure one out together. Yeah. AUDIENCE: [INAUDIBLE] SPEAKER 1: Yeah. One way is we could put the name property on the global object. So we could do something like do you think it matters whether I do it on line 15,17, line 1? Where should I put this? AUDIENCE: [INAUDIBLE] global object [INAUDIBLE] SPEAKER 1: Yeah. So the answer is yeah. It doesn't matter where I declare this. Because as long as it happens before line 18, this dot name will exist. So I could do something like this dot name equals Johan. Who is one of our teaching assistants. And line 20 would now say hello Johan. Actually there's a small caveat here. The way that node evaluates files, it actually won't work if we just invoke this by doing node 12. It's still going to be undefined there. That's just I'm going to wave my hand for now. It's the way that node handles invoking files under the hood. But if we actually did this in the node console right here, if we did const person equals name greet is the function. Just console logs hi. So if I did person dot greet here, we see hi, Jordan as expected. And now if we did something like const greet equals greet. We call greet there, we see hi undefined as expected. And now if we did something like this dot name equals Johann. Now if we did greet, we see hi, Johann as expected. Why? Well, because if we do this, we see that this has a key called name which is equaled to Johann. Does that make sense to everybody? Again, I'm going to wave my hand at the why this doesn't work in the node the execute a file, but it does indeed work if we try to do it in the node REPL, or if we want to do it in the browser console, it would also work. m. So I mentioned that there are other ways of setting this manually. And there actually are. So there's these functions called bind, call, and apply. And all of these take at least one argument where the first argument is explicitly what you want to set this to be. And so if we were to go back into that example, and here we wanted to do if we deleted this, and we did const greet equals person dot greet dot explicitly bind, we can define some any object that we want here, and that's what we'll get bound to the this in this particular function. So if we did bind it to some object where the name is this is a bound object then if we ran this, we would see hello, this is a bound object. Because we are explicitly bound the this in this particular function to be this particular object. Does that make sense? And the difference between bind and call and apply is that call and apply rather than returning a new function because person dot greet dot bind returns a new function where the this is automatically bound, call and apply will immediately invoke that function. So rather than doing const greet equals that if we wanted to use call or apply, we'd would do just person dot greet dot call and then pass in something there. And same thing with apply. That makes sense? So say we wanted to do this, we would see all three of those got bound. The difference between bind call and apply is that bind returns a new function which we store in greet, and invoke greet later, and call and apply just immediately invoked that. Does that make sense? So one other way to set this manually is by using ES 6 arrow notation. So ES6 arrow notation will actually bind this to be whatever this is at the time that we declare the function, rather than at the time that we invoke the function. And so if we did const person const new person is somebody with a name and greet is this new arrow notation, which we'll talk about or show many more examples in the days to come, and did consol dot log this dot name. If we did new person dot greet here we see what is this dot name at the time that we actually write this here. What is the value of this? Again, this is a weird node thing. If we did it in the command line, if we did const new person equals name new person is undefined. And why is it undefined? What is this at the time that I was typing this? AUDIENCE: [INAUDIBLE] SPEAKER 1: It's the global object. And what is this dot name is undefined. And so ES6 the arrow notation will actually bind this to be whatever the value is at the time of writing. Any questions on this? Cool. So now let's talk about something that will be important in the assignment. So browsers in the DOM. So how many people have heard of the DOM before? Most people. It stands for Document Object Model. And it's basically this tree like structure that the browser maintains in order to be in sync with what the HTML of the page declares. And so say we had some very simple HTML file which was just something like HTML, it had a head with a title, it had a body with H1 and a paragraph. This can be expressed in sort of a tree like model, right? We have the document, we have inside the document we have some HTML, what's inside the HTML? Well, we have a head, and we have a body. What's inside the head? Well, we have a title. What's inside the title? Well, it's some text called this is a simple page. What about the body? Well, we have an H1, and we have a paragraph. And what's inside those? Some text as well. And so we can sort of describe that as a tree, right? We have at the very top a document, and below that we have some HTML. And what was inside the HTML? We had a head and a body, right? So had a head and a body. And what was inside the head and the body? Well, the head had a title. The body had a couple other tags, H1 and a paragraph. And so we can sort of describe those also as part of the tree, right. So head there's a title. Body had an H1 and a paragraph. And those each had some text. And so do you see how that HTML maps onto some tree like structure that we can maintain? So this tree like structure is called the DOM or the Document Object Model. And it's the way of modeling the HTML that is rendered onto a web page. Does that make sense to everybody? And so why does that matter? Well, we can actually modify that DOM using some JavaScript. And as we'll discuss in section this week, we'll discuss exactly how you might do that. And that is exactly what the first project is going to be covering. So in the first project which will be released today, you will create a to do app. And so the to do app will basically be a way of tracking some to dos that you'll have to do. And you all use JavaScript and DOM manipulation in order to create and track however many to do's you need to check off. There'll be specifics coming out via email. But this assignment will be due in a couple of weeks. And sections will also be starting this week. You should have gotten email before class today with a form about a couple sectioning times and if those work for you. And those sections will be starting this week. And sections are basically 1 and 1/2 hour, 1 to 1 and 1/2 hour block where led by one of our TAs, Johann or Raylen, will be talking about smaller stuff that we didn't quite cover in lecture. One of these topics will be DOM and manipulating the DOM using JavaScript. And so this week, they'll be talking to you about that, answering any questions that you may have. And then preparing you for this first project. All right. Let's call it for tonight. And I'll stick around for some questions if you have any after.