Introduction

Good morning, good afternoon, good evening, no matter where you're coming from, hope you all are doing well. Welcome back. We online, let's go everybody. Hey, what's going on? Welcome back, everybody. Hope you all are doing well. Hope your week's been off to a good well. Hey, thank you for all the birthday wishes. I appreciate that. Hey, thank you, everybody. Hey, all right, turn up. What's going on? It's so good to see you all. Crisis, hey, thank you for the five gifted subs. Thank you for being here.

Hey, welcome back, everybody. Woof, woof. Got your third client this month, 8K, let's go. Turn up, that's huge. Eight grand already, what? Let's go. That's amazing to hear. Thank you for sharing that. 8K in chat, woo, woo. We out here doing things, folks. We outside, we online, let's go. Welcome in, everybody. All right, thank you for the birthday wishes. I appreciate it. Folks are asking, the wife is doing very, very well.

Minor car accident, just wanted to make sure everything was okay, so we're in the hospital for a night, but doing perfectly fine. Everything's going well, so I appreciate all of the outpouring of support. People were, I had people DMing me in Pokemon. on like reaching out all over the place to send good vibes and well wishes. So I appreciate all the support. Thank you for everyone that sent me a message. I can't respond to all of y'all, but I appreciate it. Thanks for coming through. We got a lot of fun stuff tonight. Double dizzle. Hey, thank you for the gifted subs. Rufio with the raid, 146 folks, 146 with the raid. Like I always say, folks, if you you got some time before stream, there's nothing better to do than to be in Rufio stream before this stream. You get the raid. Oh, oh.

They were at two hundred and eleven. Let's go turn up. All right. I appreciate when I came through with the raid. Everybody is hanging out with the stream team. I appreciate you all. Wife's doing well. I appreciate all the good wishes. Got a lot of fun stuff to get into tonight, folks. I promise, I promise I'm going to blow your mind tonight. When I was learning this stuff, oh, when I was learning this stuff, it's like a whole new world opened. I felt like, I felt like Dr. Strange opened a portal and I stepped through it and everything was different. So I'm hoping that's for you. The, the, the, like you see, you see what's behind the curtain and we were in Oz the whole time.

So I promise that I'm going to blow your mind and then we're going to get to node so we can be full stack software engineers. By the end of tonight, you will be a full stack software engineer. What? Let's go, turn up. A Copper Lily A, glad you're able to join us live. Web 2A, welcome. Let's go. Got the gang in here tonight. Let's go. All right. So as always, I like to start off with some questions, questions. I got answers. We'll do the question. I'm going to say that question the day to Tuesday, because we had so many people in here saying happy birthday. We got questions.

I got answers. Always like to do this for a little bit to give folks a second to get in here, to get situated, to get things set up, to get the things downloaded. it almost caught up on YouTube. Should I start live with back end? Yeah, join us tonight, join us tonight. Cause this is going to be like the, the, we're going to just get a little nibble of node, but it's more about like, what is node? That's the goal of tonight. Like, what is it? How, what are we going to use it for? My resume isn't done, is there going to be another opportunity to check yes for wanting it shared? Not ready, but it will be. No, just don't fill out the form until Tuesday. You'll notice that I shared the form for you to submit your professional links, but But then if you peep the homework for this weekend, I asked you to finish it. So not everyone is finished. So take the weekend to finish and then submit it on Tuesday.

Yeah. If we are just getting into JS, should we attend this class? You can, but your mind's gonna be blown. I think if you haven't started any JavaScript, like if you haven't written any JavaScript, then skip this one and come back later so you can officially have your mind blown. But if you've been doing a little bit of JavaScript, you're doing click events, event listeners, or stuff like that, then this is still up your alley. So here's the thing. If you submit these links, you can just update the links. Like the links aren't going to change, right? So even if you edit your resume, even if you edit your stuff, like the link's still the same. So just edit it and I'll have the updated version. Don't resubmit though. That, that, that, that causes me too much headache. Like don't keep respamming like links either submitted or don't submit it, but don't keep respamming it because that's too hard for me to get track of It because of problem. So yeah, don't just don't keep like don't spam resubmit just update your links. That's all And and no worries that like this isn't like the official thing like Eventually, we'll have places where you're gonna upload everything where you're gonna share all the official stuff with me Like, don't, don't freak out like that.

It's not perfect. Um, you'll have, you'll have time to make it more perfect, but this isn't like, we're going to put you up on the, on the internet with this stuff. Now I would never do that without asking you first. Cool. Networking and finding clients has been a struggle being so behind on these two things as all my hard work been a waste. Uh, it's not a waste. It's just that we know that the networking is the thing that gets you jobs. And so there, remember we talked about all these doors being opened. The whole point is to open as many doors as you can. Not everyone has the privilege of opening all the doors. And so the networking opens a lot of them, but there's still opportunities if you're kind of behind on that aspect. So you should still push yourself to get that done, to unlock that, to be more focused when we get to the hit list, but know that it's all about opening as many doors as possible. and some folks can open one and two and really go ham on those one or two and get an opportunity, but it's about being prepared. It's about opening as many doors so that we can get the opportunities coming our way. Cool.

Are we still letting people into the 100 Devs LinkedIn group? Yeah, I haven't been able to let anyone in in the past couple of days, but if you keep signing up for it, I'll keep letting people in. Always feel free to join the classes live. You don't have to worry. Yeah. Can our a hundred hours project be in react? It can be, it still has to be a full stack web application, but if you want to include react, sure, no worries. All right. Alrighty folks. Let's get into this. So we got a lot of folks in here. We're gonna do some great things tonight. We're gonna talk about callbacks, promises, async await, and then node. And then we're gonna start building full stack web applications. I'm excited you're here.

Let's go ahead, let's get into it. We got some things to do before we jump into the learning tonight. And so as always, if you haven't checked in yet, Please check in I can always do exclamation point check in here to get the link You still have to click the link like and retweet on Twitter. Remember you have your fresh start So your past attendance doesn't matter But your attendance starting now does so make sure you're doing the liking and the retweeting so that we know that you're here in class It also helps folks find us. They don't want to spending twenty thirty thousand dollars on a boot camp. They can come here and community get community taught, folks, get community taught. So appreciate the check-in. We're gonna do office hours on Sunday. So Sunday, 1 p.m., our traditional office hours. We're gonna come, we're gonna answer some of your questions. We're gonna talk more about Node. It'll be a good office hours. Our office hours are always chill. We're not gonna do anything on Friday this week because I still need some time to catch up because I missed a couple days due to the accident. So just the regular office hours on Sunday is gonna be a good office hours I'm hyped for it.

And then next week we'll start doing like the car practice prep practice all that fun stuff cool Alrighty Newsletter. Oh boy. There was a newsletter raffle. Let me go ahead and grab folks from the newsletter raffle Remember newsletter goes out every day before class all the goodies are in that newsletter before class And so I'm just gonna go ahead and I'm gonna plop everybody's name that filled out the newsletter raffle already. And I'm telling you, there's gonna be some good stuff coming up in that newsletter raffle. We're doing VIP today. VIP just helps you, it makes you stand out here on Twitch. You can flex on your, be a good old flexasaurus, if you know what I mean. All these people trying to get in here. You're too late. Shoulda opened the newsletter. You should open the newsletter. All right, I'm gonna grab all these names real quick. And we're gonna plop them into the name picker. There were 953 of you all that opened it before class start.

Well, at least, not saying opened it, but at least filled it out. So we have a lot more people in that newsletter than that. Let's go ahead and paste it in. Here are the names that filled it out before class. Let's go ahead and pick a random name here And then they're going to get VIP. All right. Flick flicks, two, four, six, eight. You get VIP. I'm going to go ahead and do that right now. VIP isn't forever, but it's for a good time. All right. Look, look, she got VIP congrats. Like I say, always folks, it pays to open the newsletter. You can do exclamation point newsletter to sign up. If you're worried that you haven't been signed up, you can always try resubmitting it again.

But yeah, I switch point newsletter doesn't sign up for the newsletter. You have to click the link to sign up for the newsletter and fill out your information. Alrighty. Congratulations. The flick flicks, you now VIP. Feels good. Don't it? Alrighty. Today's my birthday. Thank you for all the birthday wishes and, uh, well wishes. And so I, I have a, I have, I have a birthday wish to ask of you all a birthday wish, right? You're supposed to keep your wishes to yourself, but I'm going to make mine public. My birthday wish is that you follow every person that's on the new people that have joined the stream team recently. This is in descending order of the folks that have joined recently. And so if you haven't followed Fox, Minewolf, Rufio yet, please follow them on Twitch.

And if you haven't followed them on Twitter yet, please follow them on Twitter. Dakota, Dakota, hey, thank you for the 10 gift subs. I appreciate it. Thank you so much. Thank you for being here. All right. And if you haven't turned on notifications in the stream team channel yet, please go ahead and turn on the, we only post, we only post when we're going live and we only post when we're going live and we're working on code related stuff, right? So no spam, no anything. It's just stream team members. It's just when we're going live, working on good code related stuff. And so if you haven't given them a follow yet, please, if you haven't turned on notifications for the stream team channel, please, that's what I want for my birthday, folks. That's my deep-seated birthday wish. I really hope that you give these folks a follow. I really love this idea of being community-taught. So many people say they're self-taught.

That's not what we do here. We're community-taught here, right? We learn from each other. We learn from each other on Discord. And my favorite thing is going to fellow stream team members and seeing the things that they're working on and seeing so many of you all there working along with them, doing code wars, doing review from the things that we covered in class, you can pick up so more, so much more amazing things by hanging out with our stream team members. So I hope that you, uh, if you, if you look here, look, let's get real for a second. If you put half the happy birthday in the chat, but you didn't follow them, it was kind of, it was kind of all cap, right? Like you didn't really mean it. It really mean happy birthday. Like you just kind of, you know, everybody else is saying, let me say, you know, you know what I'm saying? You know what I'm saying? So you're already kind of committed, kind of already locked in. All right. Thank you. I appreciate you all.

Thank you for being here. All right. We talked about our fresh start. You got right talked about our fresh start Meaning that in the past the things that you did didn't matter They like the slate has been wiped clean. You forgot the check-in one or two classes. That's okay You forgot to submit a homework or two. That's okay. Your fresh start starts now. You got a check-in starting today You got to start submitting the assignment starting today, right? So the slate has been wiped clean and we do that so that folks that are joining us and still get all the wonderful goodies that we're going to have at the end of program. So the checking in is important. The submitting your homework on time is important. It helps me when we're doing things like. Reference calls for me to be able to say, yeah, this person always shows up on time, right, like I want to be able to when I talk about people, I talk about them in the most positive light possible. And I use real things.

So when somebody I'm on a reference call with someone like, yeah, They showed up every day perfectly on time, never missed a day. And I'm telling the truth. Cause I can see that you checked in every single day, right. As class started. So I can, I feel comfortable saying, yeah, every single day they showed up, they did their things, they submitted all their work, they got everything done. Right. Like I want to be able to talk about you in that light. And so that's why the checking in is important. That's why submitting your homework on time is important. Right. My wife says I just got a hundred followers in five minutes. Let's go turn up. All righty, let's keep pushing folks. The networking is coming back. We got to start the networking, right?

Right? Would there be a separate bank list for all those that want to freelance only? No, because it's not the path that I'm laying out here. This is not a, I want to freelance type of experience. I love freelancing. I think it's to be something that's to support you, Uh, but I think you should get a job, uh, because freelancing is such a hard, difficult beast. It has so many pitfalls and I've seen so many of my students get wrecked because they have a down, a downspin, right? Where they, they have three to six months without really any significant clients. They're not making the money that they need to make, right? So I do really recommend you get a job first, keep your freelancing game going. And then once you have a bunch of evergreen clients, right, like clients that keep coming back to you, paying you month after month, year after year, then you can go full time freelance. Now, that's up to you. If you want to take that advice. I just seen too many of my students burn out, so I just don't advocate it. I think freelancing is a great supplement, but not something that I would tell any of my students that are at this level to go full force on.

You need to have really good, like you got to have really good client skills. You got to be bringing in consistent clients. You have to have a really good emergency fund to weather out three, four months of no clients. Right. And sometimes you might have three months with no clients, but then you do get a client, but you're not getting paid until like another month, two months after that. Right. Like it's too much of a grind and I just wouldn't want that for folks. And so, um, I'm never going to present alternative paths. I want you to get a job first and then I want you to freelance on the side. And then when things are going really well and you feel like it's the time's right, then go full bore on freelancing. Yeah. Yeah. Not that it, yeah, exactly. Not that it can't be done. It's just, it's a way more difficult road.

Just got paid by a client who owed since January. It's real out in these streets, folks. Anthony said, freelance for about three years when I first learned to code. It's definitely harder that way. What you're saying is totally correct. And just in case someone wants to hear it for someone who did it. Exactly, I feel that. All right, give me that healthcare. Exactly, I love your name. Panic at the Discord. That's such a good name. Alrighty, folks. Went to a JS meeting last night, met up meeting for other 100 devs. That's awesome. Feels like the Spider-Man meme.

All right. I had a client hold a payment for 11 months of 70K. Dude has some internal budget stuff really screwed me in the ear, that's wild. Sorry to hear that, Brashless. All right, folks. Networking comes back this week, meaning that I want one coffee chat this week. I want one coffee chat. Last week for a coffee chat, I'm asking you this week for a coffee chat, right? Right? I want you to get that free, that networking coming back, And soon we're gonna be doing our networking in a targeted way, meaning that we're gonna be just trying to network with folks that are on our hit list. Let's get comfortable with it again. Let's try and get these connections going again, right? Let's keep it pushing. All right, use the sheet, folks. Use the sheet.

If you're not keeping track of your networking and the sheet, you're messing up. If you're not keeping track of your hit list and the sheet, you're messing up. Hit the sheet. Expansion point sheet and chat if you need it. All right, there's a checklist. I'm starting to ask for all the professional links today. I know some folks weren't able to finish everything, so go ahead and take the weekend to finish it, but I want your professional stuff done by next Tuesday. We gotta get the links marinating. We need the link in to start getting the recruiters to see it, right? We need all these things done so we can enter into the hunt appropriately. Remember, you should be pushing every day. You should be doing a CodeWars every day. And you should be pushing that CodeWars to GitHub every single day because our recruiters love those green squares. They do, they do, they do. And we know the benefits of spaced repetition.

We know that if we're doing a CodeWars every day, by the time we're in the interview, we're gonna be lean, mean interviewing machines. So please, please, you only listen to me with one thing. Just do a code wars every day and push it to github that your github looks look sweet You're getting that practice and you get in that space repetition in you're getting that pattern recognition and by the time you're ready to interview Well, you're ready. I'm telling you folks other people ain't doing this definitely not for as long as we do it Just a simple man cultivating my green square patch All my links are gifts now. Hey, let's go turn up. All right. Submitting your work. Uh, I asked you for your freelancing information today. Uh, freelancing was due on Tuesday. So y'all got two extra days. I want to hear if you got a client, if you got a volunteer or if you got a open source contribution. Um, so fill that out. So I know what you got. Um, later on, I'm going to ask for like the links to everything, but I just kind I didn't want to get a pulse on where you're at, what you did. And then I'll ask for like submitting everything.

I just want this to be quick and easy. And then I'll ask for all the actual details later. Same thing for submitting your work. There's a lot of stuff that was due today in terms of the 100 hours project, in terms of your professional checklist. So make sure today you fill out that link. I put both the links are here in the slides to this, But they are also in the in the discord. So on our following materials channel, you can find all these links as well. Congrats, Archer, that's huge. And please remember, so we said this already, but we know that space repetition is the key, folks. We know the space repetition is the thing that's gonna help us get jobs. Keeping up with your Anki, keeping up with your Codewars, keeping up with the homework. All this stuff becomes even more important because we're ready to get serious. We're about to enter into the hunt. We're getting prepared for the hunt and we're sharpening our poles. We're grabbing our shields, but we're getting ready.

And so we need to be getting ready so that by the time we're interviewing, we're good to go. Some petty patties were trying to tell us that green square back getting was cheating. Don't hate the play. I hate the game. Yeah. I think that's a very clear. Don't hate the play. I hate the game situation. I really committed. I committed to doing a hundred days in a row. And there were a few days where I had to change my, my time to Hawaii. I didn't, I didn't do like the commit thing. I just, I just changed the date and time on my computer to Hawaii because I missed it by a couple of hours. So I don't know. I I'm going to count it.

Like I said, I'm a by any means necessary type of person. If you, if you, if you are a recruiter that can dig through my get history and figure out that I backfilled some dates, well, you're just impressed me. That's that's for sure. All right, tonight folks, we get into the back end, we become full stack web developers. We combine our front end skills with some back end skills. But before we get to the back end, we have some things to cover. And so we're going to start off with a few things that are going to help us better understand where the back-end comes to play that helps us better understand like what we're doing when it comes time to the back-end. So give me a chance to work through some examples tonight. They're going to help us see some other really key things that we need right before jumping into the back-end and know that a lot of these examples are just examples. I'm gonna use some words very loosely tonight. I can already feel the nerds shaking and quaking Leon that's not asynchronous Leon. That's not that's not secret. That's not what that's not what that's not the definition Oh, all right. I can already hear them. I can hear that.

You hear him Yeah, you can hear like the there's like a sound I love you can hear it All right, I think I have to talk while I do it talk talk There's like that sound, it's like the fist clenching and the teeth, like, oh, and they do a little shake, right? I can hear it. I can hear a little bit because I'm going to use some words and I'm going to use them loosely because we're here to freaking learn folks. We're here to learn. We'll worry about the nerd stuff later on. We're here to learn. So I'm going to use some words loosely. Give me some room here. Let's stretch out. Let's take deep breath. All right, folks, we got this. We're here to learn. All right. And so we're going to start off by delivering some papers this evening. Uh, and I am going to take on the role of a paper delivery person and we're going to deliver some papers.

Now, some of you are like Leon, what the heck are papers? Uh, well, papers are news. Well, almost normally news that are put on two sheets of dead trees. So we used to chop down trees and we would turn those trees into like compressed sheets and then people would write on them and then print on them like they would they would put like um like ink what is ink you know like like what a pen is the stuff inside of a pen they would put that all over the sheet and then like your grandparents would read that every morning so it's kind of like it's kind of like reddit but on dead trees so that's what papers are. Cool. All right. So we're going to be a person that delivers these papers because every morning someone used to drop off a paper at your house and that's how you read the news. So instead of like logging onto your computer, you would just like go to your front door and you were like, open it and boom, there you go. Boomer stuff. Exactly. All right. So let's deliver some papers now. What do we want? If we're going to be a good paper delivery person, we probably we probably need to do something well. And so we could be a paper delivery person that we get on our bike, we have all our papers with us, we ride our bike to the first house, we throw the newspaper at the door, and then we wait.

We wait for them to kind of like wake up, put their pajamas back on, they come down the steps, they open the front door, they grab their newspaper, and then we get back on our bike, we hustle to the next door, we throw the paper at it, and then we wait. Eventually they get up, they have their breakfast, they come to the front door, they open it, they grab their paper, and then we're like, ah, we gotta get to the next house. This would be a really inefficient paper route, right? We would call this synchronous for now, where we are kind of just like waiting for each person to get their paper before moving on to the next house, right? What we'd want is for ourselves as a paper delivery person to be asynchronous, meaning that we would throw the paper at the door and then we move on to the next house, right? Now, the cool thing is that when we have a synchronous process, there are some things that we get that are perks, right? There are some perks to having a synchronous process where we're throwing at the door and then waiting before we move on to the next one. What are some perks that we might get? We might get tips, maybe we can be pretty certain that they got their paper, right? Like we saw that we, we, we threw it, we saw that they eventually got it. So we can see that they eventually got their paper, right? but that benefit that we get is vastly, vastly not worth it. We probably value the idea of serving a thousand people and losing a paper or two, then serving five people a day and that's it, right? And so there's this idea like we could be waiting or we could be just doing our business and hitting each door and moving on to the next one. Now, JavaScript as a language is single-threaded and it is synchronous, aka it can only do one thing at a time.

And so it has to wait. It's gonna do one thing and then it has to wait until that thing is done and then it moves on to the next thing. By single-threaded, I mean that there is only one newspaper delivery person on this route, right? We could have a language that waits and we could fix the problem by having multiple paper delivery people running around the neighborhood, but JavaScript is not like that. JavaScript is synchronous, meaning it blocks, like it waits for the person to come get the newspaper before it moves on to the next house. And it's single threaded. So it means there's only one paper delivery person, right? We could eventually have languages that are multi-threaded where we have a bunch of newspaper delivery folks, but JavaScript's not like that, right? So we have one paper delivery person and they're synchronous, meaning they wait. And so that makes JavaScript maybe not the best language ever, but it also raises a lot of questions. Or maybe it makes it a great language. We're gonna have to figure that out. So if JavaScript is synchronous, right? Meaning that it has to wait before moving on to the next thing that it wants to do. Right?

It has to wait for it to move on to the next thing that we want it to do. How do we do stuff like make API requests? Or how do we do stuff and then keep scrolling? Right? How do we keep clicking? Like it just seems like this language would just hold us back. Like if we are on Instagram and we like a photo, we can immediately start scrolling. But you're like, Leon, you just told me that JavaScript is synchronous. It's single threaded, meaning that we have to wait. We have to wait for us to like the photo, for all that stuff to happen before we can keep scrolling. But that's not our experience when we're using JavaScript. When we click on stuff, we can still do other stuff in the browser. It's not, it's not waiting. We're not, we're not seeing that. We're not seeing what JavaScript should be doing, right?

We know that JavaScript is single threaded. It's synchronous. It should have to wait for something to finish before it does the next thing. Jason Derulo, hey, thank you for the gift of subs. Thank you for being here. So if JavaScript is single-threaded, if it is synchronous, how do we do all this stuff that we're just so used to doing in the browser? Click events, fancy stuff in the DOM, like how are we able to do all this stuff and not just have to sit there waiting, counting our time before we move on to the next thing? Well, things should block. We should have to wait, but they don't because of the environment in which we are running JavaScript. JavaScript is single threaded. It should block. It is synchronous. It should have to wait for one thing to finish before moving on to the next one. But because of the environment in which we run JavaScript, we don't have to. And so when I say the environment, I don't mean like this, like the earth.

I mean this. Yeah, baby, this is what I'm talking about. Take a look. Talking about the browser, baby, exactly. Our JavaScript is running in the browser. And since it is running in the browser, we get to do some stuff that JavaScript on its own would not be able to do. JavaScript is single-threaded. It is synchronous. It should block, but since we're running it in the environment that is our browser like Chrome, Firefox, Safari. Since that's where we're running it, we get to do a lot of stuff that we shouldn't be able to do. Our JS is running in the browser, and since it's running in the browser, the browser gives us a bunch of APIs. It gives us a bunch of simple interfaces that we can use to do really complex stuff, right? The browser gives us a bunch of APIs that we can use that are asynchronous and that can enable us to keep looking at our cute cat photos while certain operations are being processed asynchronously. So JavaScript is not an asynchronous language, but it gives us when we run it in the browser, we get access to some APIs and the browser APIs can do all that asynchronous stuff. Just to be clear, it is not JavaScript doing this stuff.

We are making the request that the browser do this stuff that JavaScript can't do. So, you're saying, Leon, the browser gives us some APIs. Let's look at some of these common browser APIs. And this is something I did maybe 10 years ago. And I was like, all right, so hold on, wait a minute. All right, hold on, hold on. So JavaScript is single threaded. It's synchronous. It should block. it shouldn't be able to do anything. Like we shouldn't be able to like click on something and then immediately start scrolling. We should have to wait for that click to finish and then start moving. So you're telling me that JavaScript can't do that by itself, but since it's running in the browser, it gets access to a bunch of APIs. And those APIs are gonna do all the heavy lifting for us. Tell me about these APIs.

Tell me what the browser can do for us. And so we can look at this huge list of web APIs that since we're running JavaScript in the browser, we get access. I got to clean my glasses real quick, hold on. Y'all see that? Y'all see that, did you see it? Something happened. Now I'm not, I'm not feeling too good about it. Let's take a look. Hold on. Dom. Oh, I got to turn on my demo pro here. Dom. Hmm. All right, hold on, Leon. Hold on, hold on.

Hold on. Wait, wait, wait. Wait, hold on. So JavaScript, single-threaded synchronous should block. It's able to do some stuff because we're running it in the browser because the browser gives us access to some web APIs and the web APIs do all the heavy lifting for us. One of the APIs we have access to is the DOM, the document object model. And so when I read that in the list, I had to go look this up. I'm like, wait a minute, the DOM is an API? And then I read, I believe this is like on Stack Overflow from like 10 years ago. This is what I read. Because I saw that on the list. I'm like, wait a minute. I've been using the DOM the whole time I've been writing JavaScript. What do you mean that it's a web API? Hold on.

So I read this on StackOverflow like 10 years ago. The DOM, aka the document object model, is essentially the API one uses to manipulate an HTML document, usually using JavaScript. Usually, excuse me? We got, got, we got, got. Hold on, I got to read this again. The DOM is essentially the API when uses to manipulate an HTML document, usually using JavaScript. Okay. Okay, so this means that the DOM is something that the browser gives us access to. JavaScript doesn't have the ability to access the DOM on its own. The browser is the thing that enables us to access the DOM, which means that technically the browser could give any language the ability to access the DOM. And it kind of happened. If you went back to the beginning of the browser wars, Netscape Navigator created JavaScript. Well, the person that was there wrote JavaScript. And then Microsoft was like, screw that. We're going to write, I think it was like J script or live script, something like that.

And then Firefox was like, nah, we can't do this. We got to have like one like unified thing. And then they came into like, and then we had the browser wars And eventually, after this huge hot mess, we had the ECMAScript Council. And the ECMAScript Council is like, hold on, this Internet thing is getting away from us. All of our browsers need to be on the same page. We need to be exposing the same APIs that when folks are writing JavaScript, it works in the different browsers because the DOM is not something that comes with JavaScript. I literally remember screaming like, what the fuck? I was like, this was like starting to like make sense in my brain. I just remember like saying like, what the fuck? Like I was just, I was, I, poosh, poosh, poosh, poosh, poosh, poosh, poosh. And so I was like, all right. Document.querySelector, right? Document.querySelector is not JavaScript. If we look at like JavaScript, like the language and we look at the language and everything that comes with query select, there's nowhere to be found. We only get access to the DOM and the document and all the methods that are associated with it, like querySelector, querySelector, all because we are running our JavaScript in the browser.

If our JavaScript was not running in the browser, we wouldn't have access to DOM, Document query selector all that stuff has nothing to do with JavaScript It's because we are running our JavaScript in the browser that we get access to all those goodies So, yeah JavaScript can do a lot of the blocking stuff because the browser is handling all, handing all that blocking stuff, right? It's handing all that stuff over to the browser, right, it can do all this blocking stuff because it's handing it off to the browser and the browser, it makes sense because the browser is a program that's running on our computer, right? The browser is a program that's running on a computer. It can access our CPU, maybe access our GPU, right? It can be multi-threaded, it can do all this wonderful stuff. So we're handing these asynchronous tasks off to the browser via web APIs, right? They're doing their thing, and eventually they're going to respond. And so this is where we get into a little bit of a sticky situation. JavaScript is single-threaded. It is a synchronous language. It should block, but we just found out the reason why we're able to do all these asynchronous things like click and not have to sit there and wait for a minute before we get our response to move on is because we're handing off all that asynchronous stuff to the browser. The browser does all those asynchronous stuff things for us. JavaScript keeps running. we're handing off all that asynchronous stuff to the browser. And eventually that browser has to respond with the stuff.

And so the way that we handle the responses that come back as the result of these web APIs are things called callbacks, promises, and eventually async await. Now there's a lot of other really more complicated stuff at play here. There's things called a call stack. There's callback queue, web API, event loop. Like the stuff that really makes this happen, but we're gonna save that for Tuesday. We'll save all that for Tuesday, right? There's mechanisms for how this works. That's all this like fancy stuff. We'll save that for Tuesday. Cool. So we're gonna see some of this in practice by delivering some papers, but let's just go back a quick second here. JavaScript is running in a browser, which means it gets access to a bunch of these web APIs, things like the DOM and all the other crap that we see here that the browser can do for us. So JavaScript tries to do something and it just hands it off to the browser and keeps running because it's single threaded and synchronous. So JavaScript will keep running, handing off all this stuff to the browser. The browser does all this stuff for us and eventually responds.

So for us to understand how JavaScript is running in the browser, we have to understand how we're handing off these requests and getting responses. It's just like any API that we've done before where we've made a request and got a response. But instead of it going to the dog CEO API, or instead of it going to the cocktail database API, it's going to the API that the browser has. We're making a request to the browser, the browser is doing some stuff for us, and we're getting a response back. So why do we need JavaScript? Because it's the programming language that we're using to do all these things. It just so happens that we can hand off a lot of the heavy lifting for certain things to the browser. We still need functions, variables, loops, conditionals. We still need a language to have some sort of inheritance model, like prototypal inheritance. We still need all that stuff to do the heavy lifting. It's just that JavaScript is a language that by itself is single-threaded synchronous and can't do a lot of the things that we just think are actually JavaScript. They're not, they're actually JavaScript running in the environment that is called the browser, which might lead you to start thinking about something further down the line here. Some things might start clicking for you, right? But we'll get there in time. Cool.

So JavaScript running in the environment that is the browser. Since we're running JavaScript in the browser, we get access to a bunch of these web APIs. We just saw that the DOM is one of those web APIs. What the fuck, what the fuck? There is no such thing as document.querySelector like in the language that is JavaScript. We only get access to that since we are running it in the browser. Yeah. Indifference said front-end functionality. These APIs are still syntactically JavaScript. They're just not native to the spec. Exactly, they're not like part of the core language. All right. And you give me some freedom here. Give me some freedom here, right? Brain is broken.

I'm tripping. I hope so. So we saw that document that query selector is just a web API. It's not actually part of the JavaScript language. Oh, and it always has been. I feel disrespected. So JS can do a lot of this blocking stuff that is a language it shouldn't be able to do. because we're handing that off to the browser. We're like making these web API requests to the browser and the browser's like, I got you. And they're gonna do all this stuff for us. Now, we talked about this idea that, we said that that is usually using JavaScript, right? And in the beginning, we talked about this idea that, well, wait a minute, usually, So that means other folks have tried, or can still, and they still try it to this day, use other languages to run in the browser to get access to the DOM. The ecosystem is just so mature that a lot of times it's just not fast enough. But there are some things that are coming down the pipeline now, WebAssembly, stuff like that. It's just, it's always been a speed thing.

You can write Python that interacts with the DOM, it's just not as fast. things like PyScript, stuff like that. It's just not as fast. We were built to work with JavaScript in the browser. It'll take a long time before it kind of catches up. Cool. So we're saying usually, but this actually, this is one of my favorite things, right? It's one of my favorite things that, that like when it started to click for me, I made sense. So back in the day, if you go back 10 years, we didn't actually write JavaScript. We wrote something else. Like it was the really popular thing to write. We didn't write JavaScript, we wrote something else. Anybody know? Yeah, we wrote jQuery. We wrote jQuery.

And jQuery provided one really important thing. Does anyone know what jQuery actually gave us? Anybody know? It gave us cross-browser compatibility. You can write your JavaScript once, and it would work in all the different browsers. So that leads to a question. Why would the JavaScript I write run differently in each browser? Why would the JavaScript I write run differently in each browser? Different APIs. Each browser was giving us different APIs. So the JavaScript that we wrote, it might work in one browser, but the API might behave differently in a different one, or they might not give it to us at all. And so we were trying to write JavaScript, but JavaScript only works because it was running in the browser. But if the browser was different, it might implement JavaScript in a different way. It might not give you access to the things that you needed. And so we had jQuery.

jQuery came in and saved the day. You would write JavaScript once, and it would work across all of the browsers. All right, but now we have the ECMAScript Council, right? Folks came together. We had folks that set up better standards, a web standard that we got all the different browsers to agree to, all the different companies to come together and say, all right, here's how we're gonna implement JavaScript in the browser. Here are the core web APIs that we're all gonna agree to. And that's why we don't really need jQuery anymore. we don't need jQuery to figure out how to take the JavaScript we wrote and make it work within all the browsers because all the browsers kind of play well and nice together. They kind of all agree to this standard, right? And so as all the companies came together, as all the browsers came together, as the ECMAScript Council kind of matured, we don't really need jQuery anymore because the biggest thing it gave us was cross-browser compatibility and maybe a slightly simpler syntax. And so yes, Niles, that's where ES6 comes from. ECMAScript 2015, 2016 forward is where we start to see all the browsers really, really starting to play nice. All kind of taking the same JavaScript and making it run well with their web APIs. And so it really did change the game, but I hope that you understand that, all right, JavaScript is a language, it's running in the browser. And since it's running in the browser, and get access to all these web APIs.

And back in the day, different browsers gave you different APIs, or they did things differently, or they just weren't the same. And so the JavaScript you would write would break across all these different languages. We had jQuery. jQuery was written to figure out how to handle all these exceptions in all the different browsers, and it made your life a lot easier. But now that all the browsers kind of are working together, we have a set of standard APIs that they're all working with, we get the ability for us to write JavaScript once and to work in all the browsers. Cool. So we can make our own DOM. Well, if you started your own browser, you could create your own DOM API that would handle things differently. You could do that. Yeah. Why do we still use jQuery then? I don't think really too many people still do. I think maybe there's a lot of legacy code that might use it, but it's redundant. Exactly, it's redundant now. We don't need it for the cross-browser compatibility anymore.

So like one of the biggest things that gave us is no really longer like necessary. Cool. All right. So we have this idea that JavaScript, which is normally a blocking language is handing off all these important requests to the browser. But eventually, the browser needs to respond back to JavaScript so we can use the responses. And so what do we do to listen for those responses? What are the tools we can use so that as these web APIs respond, we can do stuff? And so that's going to take us through callbacks, it's going to take us through promises, and eventually the newer async await syntax. So when we come back from break, we're going to jump into delivering some more papers. I'm going to give you really clear examples on callbacks, promises, async await. We're going to talk about all these wonderful things that enable us to hand stuff off to the web APIs, that enable us to get response, to make JavaScript run in the browser. We're going to get really comfortable with that. And then we're going to take ourselves to the back end. Oh boy, hope your mind's blown a little bit. I hope that you like the idea that like document and query selector aren't actually JavaScript, they're web APIs.

I hope that just like ruptured your mind for a bit. We'll be back in five minutes. If you're new around these parts, we love to take breaks at the top of the hour. We're here to be, we're here for the long haul folks. If you're able, get up, move around, hydrate, walk the dogs, kiss some babies, Stretch, look out the window, let your eyes focus on something that's not the screen, and we'll be back in five, folks. Really excited to kind of jump into these callbacks, promises, async await, and then The sweet sweet sweet back end, baby Earth so welcome you can do exclamation point 100 devs to learn everything about the boot camp Uh, we do have a two plus extension on the timer And a hydrate Oh snap. Thank you for the hydration and we got to add two minutes to the timer I didn't see it because this goes to zero. We'll add two more minutes. Thank you. Android. Thank you. Oh snap All right, we're in two more minutes Android X 117 and a few minutes to the timer more time to help my brain a different this is one of my favorite classes to thank you for saying that. I think this is up there. This is top three for me. So much amazing content.

Do you wish you were creating in the error of the blog when it was all searchable and easier to access? Nah, my goal is to get folks jobs. I think this is the ideal format for that. I think there's plenty of like books or tutorials you can read. I think there's something really important about being like live with a cohort of other folks. It's their self-study community studying, right? I think that's, I think that's really important. So I think, I think it's the right time. I think it's the right moment. I do wish I was better at like making the content into other content. I still have time for it. The grind is ready to creep from getting burnt out. I plan out my days I plan in leisure time planning time with my wife Yeah Make sure I don't go into my weeks like an accident really does help with burnout All right, take breaks when I need it All right folks come on back come on back Does your wife know that Dom isn't JavaScript? Keep that to ourselves. All right, folks, come on back.

Thank you, Android, for the two-minute extension. We'll need it, we'll need it. All right. That's awesome, CD, glad you liked it. Alrighty, so we talked about this idea that we're handing off all the heavy stuff to the browser, but eventually the browser needs to like return with like the response, right? Like we tell it to go do all this fancy stuff, we need to get the response back, right? And so let's talk about how we can handle responses by delivering some papers. So I have in today's starter code, But if you need a starter code, of course, always on our Discord, follow on materials channel, you'll see it. I have this lovely starter code here inside of the async practice. This is what I'm gonna be using to run stuff in the browser. And so I'm just gonna go ahead and uncomment it. You can just copy and paste from the slides if you want. You can just watch me. There's no need for you to like type along with this. I'm just trying to show you some really interesting tidbits here.

So I'm going to uncomment this and then I'm going to open this in my browser so that I have this open. And I'm just going to keep using this file that's open in the browser. All right. So we can see in the slides that we have a traditional, a traditional kind of three functions. Each function console logs, console logs, console logs, and then we call each function house1, house2, house3. If we open up the browser here, we look in the console, we see what we expect, right? We see what we expect. Paper delivered to house1, paper delivered to house2, paper delivered to house3. That seems pretty standard because we know that JavaScript is a synchronous language. It's going to run this function, then this function, and then this function, and we're gonna go on with our lives, right? Pretty standard functions. Now, let's use a web API, like setTimeout. That's right, folks. I said it right. Let's use a web API like setTimeout.

setTimeout and setInterval are not part of the JavaScript specification. It's just that most environments include them like pretty much every browser and node. So setTimeout, setInterval actually aren't part of JavaScript. We only have access to them because we're running it in the browser and this makes sense. This makes sense. If JavaScript is synchronous, if it is blocking, how could it have set timeout or set interval that kind of like wait some time and then do something, right? Like how this it's just not possible with the way JavaScript is built as a language. it has to be a web API. We have to hand that off to someone, something else. Right? Like it has to, it's just not something that's built into JavaScript. It's just the language can't support that. But since we're running JavaScript in the browser, the environment where we're running it gives us access to it. Blocking it just means that we have to wait until everything finishes before moving onto the next thing. Right?

So like when we were the newspaper delivery person, we threw the paper at the door and we waited for the person to pick up the paper and go back inside. That's blocking. JavaScript blocks, whatever it does, it has to wait until it's done before it moves onto the next thing. So something like setTimeout or setInterval can't exist in JavaScript because JavaScript can't wait. It has to keep moving, right? Cool. You got me. This is live footage of me figuring out, right? Of me figuring out that setTimeout and setInterval are actually not part of JavaScript. Cool. So let's get a little funky with it. So here's another set of code. Here we have the house one that looks normal. We deliver it to house one. House two is a little bit different.

We have a set timeout that's gonna wait three seconds. Right, it's gonna wait three seconds. And then we have our house three, which is console.log house three. So if we run house one, house two, house three, what do we expect to happen? Like what do we expect to see in the browser? What's your guess? It's like, what are we gonna see in the, what order are we gonna see the houses? All right, let's go ahead and run that. So I'm gonna go ahead and go to my JavaScript here. I'm gonna comment out the old code here, and I'm gonna uncomment the next batch. All right, here we go. We can see that the second house two has a set timeout where we wait three seconds. House one, house two, house three. Let's go back to our browser and refresh it. All right, we see house one run, house three run, and then after three seconds, we see house two pop up.

And that makes sense, right? We know that house one's gonna run automatically. Super, it's gonna run. We know that house two has a set timeout that it's gonna take three seconds, but this JavaScript wait, hell no, it moves right onto house three. So we had one, three, two. Now, let's try something a little bit more funky. Let's go ahead and reduce the set timeout from three seconds to zero seconds. Here we were saying, wait three seconds. So it makes sense that it went one, three, two, but when we get rid of the wait, what do we expect? What's the order? We got rid of the wait. Why we're not gonna wait anymore. We got rid of the weight. Let's go ahead and run it We're gonna get rid of the weight We're gonna get rid of the way we're gonna change it from 3000 to 0 we're gonna save it and we're gonna refresh What Hold on, did I save it? I saved it.

There's no longer a wait, folks. We went from three seconds to zero seconds. I'm refreshing, one, three, two, gottie, gottie. So, hold on, let's think about this. With a three second wait, we had the same result, 1-3-2, as with a no wait. There's no wait here. We still got 1-3-2. Why? Why, why did we get got, why did we get, why did we get got? Set timeout gets handed off to the what? Set timeout gets handed off to what? Yeah, it's a browser API. So that request, even though it's no wait, it's zero seconds, it still gets handed off to the browser. And then what does JavaScript keep doing? I do like the Chris Farley.

Right, what does JavaScript keep doing? Right, it just keeps on trucking, folks, right? It doesn't care. Hand it off to the browser, boom, gonna keep going. and Kool-Aid man, right? Like it just doesn't matter. So we have the lovely house one that gets console logged. We hand this off to the browser and JavaScript's like choo choo and just keeps going, immediately goes to run house three. So we see three and then eventually, eventually the browser responds. The browser API responds, right? And so that's why, right? That's why even though there is no wait, there is still the handing off of the setTimeout to the browser of which JavaScript does not wait for. It just keeps moving. So that's why we do one, three, and then eventually the browser responds and we see two. Because even though it's zero weight, there's still some time that it takes to go to the browser and back.

JavaScript just tossed the paper and ran, exactly. Now, the reason or the mechanism behind this, and like how this works, is something called the event loop. And so we're gonna get to that, Well, I forgot to change this to Tuesday. So on Tuesday, we're going to see, right? We're going to see that on Tuesday, how the event loop handles all of these events, right? We handed off this set timeout, this API request. We hand this off to something called the event loop, and that has to run and eventually respond, right? And so what I want to spend some time tonight talking about is how do we handle those responses? What if it's payday? And I wanna get paid by each house before moving on to the next one, right? I wanna get paid by each house before moving on to the next one. So we know that JavaScript don't wanna wait. We just saw that. JavaScript was like, choo-choo, blew right past it, right? Went right on to the next house.

I wanna be able to wait and make sure I get, it's payday. I wanna make sure I'm getting paid by each house, right? Before I move on to the next one. So how can I wait? Well, I only wanna move on to the third house after the second house has paid me. And I only wanna move on from the first house. I mean, so I only move on to the second house after the first house has paid me. I'm gonna get paid by the first house and the second house and then third house and so on, right? So the real world would be like, I don't wanna keep running my code until I get the response back from my API, right? Like we're talking about getting paid or like we're talking about getting paid, but what I really, this is a real world would be is like, all right, I wanna make a request to an API and then I wanna run some code after I get the response back. I don't want the code to run until I get the response back. Right? That would suck. Like if we didn't get the response back from the API, we try to run the code, our code would just never work. It's like when you make a click event, but you put the, get the value out of the input outside of the click event.

So when you go to click on it, the value is always empty because you just move too quickly. Right? Same thing's happening here where we want our code to take its time. We want to get responses back before we move on, but we know JavaScript don't play like that. So we need some things that help us do that. Cool. The thing that we use to do this, the old school way were called callbacks. Callbacks were how we could wait for a response and then do something else, right? Way back in the day, we would use callbacks. That would enable us to wait for something to happen and then do something else, right? There are going to be so many things that we want to hear back from the web APIs, right? And then do something. And so the way we did this was with callbacks. Cool. Now, to understand how callbacks work and for all of this, we have to understand that JavaScript does actually enable us to do something pretty neat.

In JavaScript, you can have a function that takes another function as an argument. Let me say it one more time. You can have a function that takes another function as an argument, and we call that a higher order function. A function that takes another function as an argument is called a higher order function. Now, you have seen this a bajillion times, right? You've seen this a bajillion times. You have seen every single person here that's been caught up with JavaScript has done addEventListener. And in addEventListener, we had a method or a function, that took in another function as an argument. So here's addEventListener, which is our function. It took in two arguments. It took in a click as an argument, and it took in another function as an argument. And what would happen is that once this function ran, it would eventually run this function as well. So addEventListener is a higher order function. You've seen this a bazillion times. All a higher order function is is a function that takes another function as an argument.

Now, what do we call that argument that's being passed in? What do we call that function that's being passed in? Well, the function that we call, the function that's being passed in, we call it a callback. So all the callback is is the function that has been passed in as the argument in a higher order function. You've seen this a bazillion times. You've been using higher order functions. Here's addEventListener. It takes in a function. That function that we took in as the argument, we call that a callback. So higher order functions, just a function that takes in a function. The function that gets taken in, we call that a callback. Now callbacks really aren't a thing. Like, it's just a convention. It's like a thing, it's like a thing that we do in JavaScript, but it's not really like, it's not really like something. It's just a convention.

Cool. So let's get paid. And now that we understand that there are something called callbacks, where callbacks can enable us to wait until we get a response. Let's see them in action. I wanna show you callbacks and how callbacks enable our JavaScript to wait and get a response and then do stuff, right? Because remember, we're trying to use JavaScript, which is a blocking language that is synchronous, that we want to do all this stuff and not wait, while callbacks enabled us to actually wait before we did other stuff, because I want to get paid. I want to get paid by the first house and then the second house and then the third house, and I ain't moving on until I get paid. All right. Okay, so here is a way that we could make this happen. Here is my house one function, and then I am calling my house two function. And you see that house two takes in house three. Hmm, without really having to dig too deep, what does that make house two? Yeah, that makes house two a higher order function, and that makes house three a what? A callback, exactly. So house two is our higher order function here, and house three is our callback.

Now some cool stuff's gonna happen here. Here we have the same set timeout that we saw before. We have the same set timeout that we saw before. It's gonna wait three seconds. So if we're calling house one, then house two, and house three, we would expect to still see that one, three, and then the two. But because we are using a callback, we should still see one, two, three. So let's see it, and then we'll explain why. Let's go back and take a look. I'm gonna comment out my old code. I'm gonna move on to the next example here. We have our lovely callback example here. I'm gonna go ahead and save it, and then we're gonna run it and make sure it actually works. Refresh, boom, one. We wait the three seconds, house two, house three. Let me show that again, let me show that again.

I'm gonna show it, because it's really important that you see it. So it's gonna refresh, house one instantly, three seconds later, house two, and then house three. One more time, one more time, and then we're gonna look at the code. House one instantly, then three seconds, two, three. So before, we saw our code jumping one, three, two when we had the set timeout, but now we are still able to have the set timeout, But wait before we move on to the third house. Let's take a look at how that's actually happening. So here we have our normal house one function. So there's no guessing about that. We call it, it console logs house one. Then we're gonna run our house two function, but we're passing in house three as an argument. So when we pass in house three as an argument, it gets passed in, wherever we see callback, that's no longer callback, that's just house three, right? We've passed house three in as a function that we're passing in. So wherever we see callback, it's actually house three. So if we run this, if we run this, House one runs like normal, we see delivered to house one in the console. Then house two runs.

And house two has a set timeout where we wait three seconds. We wait three seconds, and then we console log house two delivered. And then what do we immediately do after we console log house two? After we console log house two, what do we immediately do? We run the callback, in this case we run house three. We run house three. So, if we watch this, house one runs like normal, we see that first console log. Then house two runs like normal, but we did pass something in, we did pass something in as an argument here. So, house one we saw printed to the console like normal, after three seconds, house two prints to the console, and then finally, the callback runs. We can see that it's running because it has the parentheses there. And then once that callback runs, we're really running house three. Then we would see paper delivered to house three in the console. So we can still have our set timeout, but have a way of waiting before we move on to the next house. Let's see it, and then we're gonna explain it one more time. So let's refresh.

House one instantly, wait three seconds. House two, house three. Right? So if we look at it, we ran house one, that's normal. We get the console logged over to house three. But now we don't want to move on to the third house until we get paid from the second. We know that the second house, they take their time. They're always slow getting their wallet out. They always take some time to get me the money. They always want to talk about what they had for breakfast. They want to tell me about the flowers that they planted. Right? They just take forever. So I can't move on to the third house, right? Until I get paid from the second.

But JavaScript doesn't like doing that, right? JavaScript doesn't like doing that. JavaScript wants to keep on trucking and keep on moving. So how do we use setTimeout and wait? Well, we have a callback. So here we run our house2 just like normal, and we pass in our callback function. So when house2 runs, right? When we run this function, house2 runs, the set timeout does its thing. It takes a full three seconds, right? Does a full three seconds. Once the set timeout is done, it console logs house two, and then it triggers the callback. Right? And then it triggers the callback. Boom. Now, the funny thing is, you have seen this so many times.

One of the most common questions I get, I'm gonna comment this out. One of the most common questions I get is when we do something like this. Document.querySelector, oop, I always do that. pre-selector button and we do add event listener click and then bob and then down here we have our function called bob the question i always get is leon why are we not putting parentheses right here, right? Why aren't we doing parentheses, Bob? That's how we call functions, right? That's how we call functions, right? But no, this would invoke it immediately. Bob would run and it wouldn't wait for the click. It's a callback, and we don't need the parentheses because somewhere in our code is something that looks like this. Somewhere in our code is this idea that we're passing in Bob as a callback, and somewhere in the code, we're gonna run Bob after the event has triggered. Right? We don't see it because we didn't actually write AdEventListener, but somewhere in AdEventListener's code is the running or the executing of the callback. We can put our Smurf on the block and they're chilling all day on the block, but once they hear the click, the callback fires. How do we sit there waiting all day long is because the callback, right?

We can't put the parentheses here because it wouldn't wait. Bob would execute immediately, right? It would happen immediately. But since we know that somewhere deep in the addEventListener code is a callback, we know that once the click is heard, there's gonna be somewhere where the callback gets executed. We just don't see it because we didn't write addEventListener. But that's something that's built into. Cool. So that's callbacks, callbacks enable us to actually wait. Callbacks enable us to be able to have things get handed off to the web APIs, wait for those web APIs to come back and then do something. The problem, however, that we're gonna see very quickly is that callbacks can kind of get out of hand. Let's see callbacks getting out of hand. Alright, we saw that our callback fired when the async task or the other function was done. So we waited for the setTimeout to finish and then the callback fired, right? We're able to do those asynchronous stuff that's being handed off to the browser. That request, that setTimeout got handed off to the browser.

So remember, JavaScript is running in the environment that is the browser. We handed that request off to the browser. The browser did its thing. Once we got the response, then the callback fired. So we were able to do all of this asynchronous stuff with a language that is not asynchronous because we had callbacks. Cool. So let's get paid by everyone. I wanna get paid by house one, then move on to house two, get paid, then move on to house three, get paid. And so I want to go ahead, right? I want to go ahead and get paid by each person. I want to get paid by house one, then move on to house two, then move on to house three. And so I simplified the syntax a little bit here. Instead of having to do like the calling of the set timeout, I just nested each of my set timeouts. So what we're going to notice here is that we have our root set timeout in house one. And then after five seconds, we'll see the console log.

And then we have a nested callback. This set timeout will run, right? Cause it's nested. And then once that four seconds is up, we'll have this other nested callback that'll run after three seconds. And so we're just gonna, just to simplify the syntax a little bit here, and instead of having to do like function passing callback, We could just nest our callbacks as well. And this works, we can run this code. So let's go ahead and run it just so we can see it. Boom, go over here and run it. And we'll wait, we'll wait the five seconds. House one, then we'll wait the four seconds. House two, then we'll wait the three seconds. House three, right? And so it's a simplified callback. It's still the same idea, like still the same idea, but we're just nesting them. And this is for examples.

I'm not teaching you like how to use callbacks. I'm just showing you the examples here. Right. And so we nested our callbacks. It's working. However, this creates a very, very hard to read bit of code. Right. Callbacks are great. We can wait. We can do asynchronous stuff. We can take our time. We could take our time and then once stuff happens, we do the next thing. But this is hard to read. This is hard for like us to work with other developers on and we refer to this passionately as callback hell. This is called the pyramid of doom, right?

As you start nesting all your callbacks and this is what we did, like this works. Because if we were waiting for asynchronous stuff to happen and then we wanted to wait, like back in the day, this is what we had to do. We built out this pyramid of doom. It was horrible. It was disgusting. We referred to it as callback hell. But it worked. But we were in hell. So what if there was a more readable way to handle asynchronous code? we know that we're gonna have to handle so much asynchronous code. So much stuff is getting handed off to the browser. The browser is gonna do its thing and then respond. We need to be able to handle all of these responses. The only mechanism that we've learned so far that can handle these responses is literally called the pyramid of doom or passionately referred to as callback hell. And this is what developers use for years.

There were like quirks and features that like to try and like fix it, but you still kind of often ran into callback hell. And so as we were rethinking the newer versions of JavaScript, we said, wait a minute, what if there was a more readable way to handle our asynchronous code? What if there could be a promise of a better future? And that's when we got promises. So with the newer versions of JavaScript, we got this idea called a promise. And a promise revolutionized the way that we handle the responses from all these asynchronous tasks. Pretty much everything underneath the hood now in terms of what these web APIs respond with or something called promises and promises like a really weird thing to understand it first, but I'm going to try my best to break it down so all of the web APIs use promises, so we have to get comfortable with them. And a promise is simply an object that represents the eventual completion or failure of an asynchronous operation and its value. Simply, it's an object that may have a value in the future, that's it. It's an object that may have a value in the future, that future, that's it. Just an object. We all know what an object is. We know objects come with properties and methods, and there may be some values tied to that object, like a placeholder. Exactly. Like a placeholder, right?

Like a placeholder kind of thing. But in JavaScript, we only have so many different types of data structures. So it's an object that may have a value later on. And the cool thing is if it's an object, our object can have properties and methods and things tied to it. And the cool thing about promises is that there are three states. Pending, fulfilled, and rejected. Remember, we're talking about an asynchronous task, something that was handed off to the browser. We're letting the browser do, and then the browser responds with a promise. That promise can have three states, pending, fulfilled, and rejected. So what I want to talk about is kind of seeing these kind of three states, the pending, the fulfilled, the rejected. Cool. Let's go ahead, I'm gonna take a look at some code here. Let me comment this out. Boop. All right.

All right. Here we go. All right. Let me. Oops, sorry. All right, cool. All right, I'll show the order here. All right, let's take a look at this. Here I have some new code. We can see that this code is giving me a promise. and I'm going to console log the promise. And then I got some funky stuff down here that we're not ready for. All right, so let's take a look at this. Let's save it, let's open it in the browser. Let's take a peek into what's happening here.

All right, we have a promise that we console logged, and we can see that it has a what. What is fulfilled here? If we kind of look at it, fulfilled kind of looks like a what? Kind of looks like a property, right? Remember I told you a promise is just an object and it can have these different states, right? Pending, right? We have pending, fulfilled, rejected, right? Can have these three states. So promise is really just an object. And so we're looking at it here. When we console log this new promise, look at it. What does, where have we seen this new promise? Where have we seen this before? This is just a what? It's just a class.

Exactly, it's just a class. So it's a class that's doing some heavy lifting for us. We didn't write it, right? We didn't write it, but it's something that's built into JavaScript now that's been written for us. And so the cool thing is we can have a promise, right? or be rejected or be pending, right? And so here is me building out a promise that has the ability to resolve or be rejected. And so right now, I have set an error equal to false. Right? So there's no error. So if there's no error, we expect our promise to resolve and be fulfilled. So when we look at it here, we can see that the promise that we console log has been fulfilled, and we wind up seeing something console logged here saying the promise has been fulfilled. So a promise is just an object that may have a value in the future, and it can have these three states. Fulfilled, right? We have these three states.

Let's take a look at them. pending, fulfilled, or rejected. And so while I'm waiting for the promise to resolve or be rejected, it's pending, which means that if JavaScript needs something right away, think about how JavaScript runs. Does JavaScript wait for anything? JavaScript never waits. but what if it immediately had an object? What if it immediately had an object that was pending and eventually that object became fulfilled or rejected? Right? So it gets the object right away, but that fulfilled or rejected can take its time, right? Can take its time. And when we build our promises, is we build them out so that they can resolve or reject. And if we look, I'm going to comment out this console lock here because we don't need to see it, but we have the promise. And then we have these two other values, the then and catch. Then and catch look like what? They are what?

We've learned about objects. We know what they are. What are they? They're methods. So, when a promise resolves, right? When a promise resolves and it is fulfilled, there's no rejection, right? What method do you think fires? But then, fires, beautiful. And if something goes wrong, if there's a rejection, if something is wrong, the promise is rejected, what do you think fires? The catch, exactly. So we have this idea of a promise, which is an object that can have a value in the future. And the cool thing is as these promises resolve, we can trigger a then or we can trigger a catch. Let's take a look at that. The then is a method on a promise that runs after the promise has resolved. Right, that's all you need to know.

We can go deeper on it, but for now, all the then is, is a method that runs after the promise has resolved. That's it, that's all we need to worry about. And the cool thing is, is that when the promise, right, when the promise, when that promise resolves and the then runs, we're passing a value, we're passing a value in as an argument. So as it resolves, we can pass in that resolving as data that's being passed into the then. And so when we look at our code, we see this. We see that we have the ability to resolve or reject. And here's what we're passing in with the resolve at this point. We're just passing like some text in. And so when we go to console log our data, what are we gonna console log? Look, what's the data that's being passed in if this promise resolves? Right now, as it stands, the text, exactly, that string, promise has been fulfilled. But if something was to go wrong, and for some reason this was to be rejected, maybe like if we changed our conditional to true, right? So now there is an error. So this if won't run, we'll have an else. And if we were to save that and go back to our code, we got the error operation has failed on line 72.

Hold on. Error operation has failed line 72. Line 72 is our what? Line 72 is our what? Our catch, since it did not resolve, it was rejected, the catch fired. So thens, when it resolves, catches when it's rejected, and we can see that here with just a very, very, very simple promise. Our promises get way more complex, but this very simple one can see if it resolves well, we get the then, and if it is rejected, we get the catch. Now you have all seen this before. People freak out when promises come on the table. We all lose our mind. We start running around the room. Leon, what are you showing me? I don't get it. Come on now. We've all seen this before.

You all have been using promises, whether you knew it or not. Ah, you got got, cool. Now, with APIs, fetch is an API that returns a what? Fetch is an API that returns a what? The promise, yeah. Now, does JavaScript have the ability to fetch? No, Fetch is a, Fetch is a, what is Fetch? The web API, it's part of the browser, right? It's part of the browser. And what did we just say? Pretty much all of these browser web APIs return. What do they all return? Promises, baby. Oh yeah. That's right.

That's right. You got got. That's right. Ooh. You feel that? I did. Ooh. So. Hold on. Ooh. So fetch is a web API. We know that all the web APIs return promises. And so then that makes sense. This whole time when we saw these thens and these catches, we were just resolving or rejecting our promises. If the promises resolved, we took the response we got and then the then fired.

And the cool thing about these thens is that they just chain. So the first then would run, once that resolves well, the next then would fire. If something went wrong, the catch would fire, right? So the idea here is that we've already used this. We've been using promises this whole time. We've been seeing them resolve or get rejected. Now we're just learning the language behind it. And the reason why we need this is because fetches take time. JavaScript can't wait. JavaScript says, hey, oh, give me the object and I'm gonna keep going. And eventually that object has a value. Eventually the promise returns, right? The promise resolves, sorry. And once the promise resolves, our then triggers and then our then triggers. If something was to go wrong, right?

So much stuff. So much stuff can go wrong when we make a fetch. So much stuff could go wrong. The server could break, the server could be down. It could reject our requests. Maybe we had too many people requesting from that API and they started blocking us, right? So the promise returns, the promise resolves, and as the promise resolves, it also has a value. And that value gets passed in, right? Wherever you see res, typically that's the value that's being passed in. as it resolves and the then method is fired, we're passing in the data that came along with that resolution as well. We saw it here. Here, we were just passing in like a string, but with the fetch, what are we probably sending along? As it resolves, what's probably getting resolved? Yeah, it's probably like that JSON object, right? So it wouldn't be a string, it'd be that JSON object that's the value that's being passed into the then, and that value that's being passed into the next then so we can console log the data.

Cool. All right, so fetch returns a promise, just like a bunch of the web APIs running our asynchronous code. So we've already used promises. We already seen the promise of a better future because our fetches work it shouldn't work javascript a single thread it blocks it should not work but since we're running javascript in the browser it does we can hand off that fetch to the web api the web api does its thing and instead of using nasty disgusting callbacks What are we using so we can take our time? A promise. Exactly. We're using a promise. Nice. All right. Let's see those three. Oh, we already looked at the three states. We already saw the pending, the fulfilled, the rejected. We can actually bring back the console log of the object. Look, this is the actual object. So the neat thing is we can actually console log the the object itself like the promise object itself And so here we set error equal to true So what what do we expect the state of this promise to be like when we console log it?

What do we expect that this promise should be like what's the state we should see on it? Yeah, let's go take a look Let's refresh We see that it's in the rejected state Right? So if we actually look at the object, we would see that rejected, that rejected property on it. Yeah. Cool. Nope. All right. We walked through this code together already. Let's get paid by everyone. This time, however, instead of nasty callback hell, we are going to use promises. So we're gonna set up each customer with a promise and that way we can use our promises to make code that looks a little bit more normal, right? It looks a little bit more like JavaScript. So let's get closer to writing some code that's readable, that looks a little bit closer to actual JavaScript and we're not falling into that nasty callback hell, right? So let's get paid. All right, here's our code.

We have house one set up as a promise, and we can see that house one takes a full second. Then we have house two, which takes five seconds, and we see house three, which takes two seconds, but every single house is a what? Inside of each single one of these houses is a what? It's a promise. We can see inside of each one of these houses is a promise. Some of the promises have a timeout that takes a second, some have five seconds, some have two seconds. But if we run this code, so let's go ahead and run it. I'm gonna comment out our other example here. Beautiful. And we come down to our new one here, code six. I'm going to comment all this out. There we go. Beautiful. I'm going to go back and run it. All right.

We see delivered to house one. That took five seconds. Then we see house two. That took, I think, two seconds and then three, right? Right. So now we have this lovely one, two, and three. It doesn't matter how long each house takes. We see the first house takes one second. We see that house two takes five seconds. We see that house to house three takes two seconds. It just doesn't matter. Each house can take its own time. We don't bug out because each house returns a promise. And down here we can chain our promises. So house one runs.

It resolves. And if the promise on house one resolves, what is what fires? If the promise of house one resolves, what fires? The then, exactly. So let's follow our thens. All right. The then fires and we console log the data. Where is that data coming from? Where is this, what data are we talking about? House one resolves, we console log data. What the heck does that mean? Let's go back and take a look at house one Where's that data coming from? Yeah, we see inside the resolve The data that we are sending back is paper delivered to house one So that is what gets passed in as data and that's why when we look at it We see in the console delivered the house one Great once this then is done running. What what happens next? This first then is done, what happens next?

It changed, it goes on to the next then. So the next then is running house two. So house two runs, right? House two runs and it too has a promise that resolves after five seconds and that's why we see printed to the console house two. Then the next den fires and we run house three. And we see that this house three is a promise that resolves. And then we see console logged house three. So this works, right? It's definitely more readable than callback hell, right? It's definitely more readable than callback hell. Callback hell, there's no way that you're troubleshooting anything. Something breaks in house two, there's no way that we're going to figure out what the heck is happening. So promises can be chained? Exactly, yep, this is called a promise chain. Yep, it's a promise chain.

And it just runs one after another as things resolve. If things went bad and it got rejected, we would see the catch. But this is way easier to resolve than if we were stuck in callback hell. However, however, it don't read too good, right? It don't read too good. Like this, this works. It's more readable than callback hell, but does this look like JavaScript? Is this the JavaScript that we know and love? No, it doesn't really look like JavaScript, honestly. And so I want my synchronous code to look synchronous, and I want it now. And so we got some new syntactical sugar, a new way to handle async responses. that is really technically still just promises underneath the hood, right? It's just promises underneath the hood, but it's a new way. It's a new way of making our asynchronous, not looking good code synchronous. And boy, does it look great.

And so when we come back from break, I'm gonna show you how to take your ugly, promise chaining code and introduce async await so that it reads good. It looks like the JavaScript we know and love. Oof. Hmm. You can be ready for it. Oh, can't wait. It's just, oh, gets my motor going. All right, folks, let's take a break. At the top of the hour. We're learning a lot tonight. Lots of new things flying at us. When we come back, we're going to make our synchronous code look synchronous. Oh, it's going to look so good. Five minutes on the clock. If you're able, please get up, move around, hydrate.

We'll be back in five minutes, folks. Oh boy. We got to get to this lovely async await. We're going to see it. It's going to make sense. It's all going to come together and then back in baby. Jay Harker added two minutes to the timer, so we're going for seven minutes, folks. Seven minutes on the timer here. Boom. Gonna make our ugly promise chains look good. Gonna introduce async await and then back end baby. I promise all this hard work pays off when we get to the back end. We're gonna see why this evolution of callback held a promise chains to async await helps us when we get to the back end. All right, folks, seven minutes on the clock. Thank you to Jay Harker 76 for the extension and run some ads.

You should take a break. I'll see you soon You You Welcome back folks. Oh, oh, it was good. All right. Let's get into it folks. Come on back. Come on back. All right. Let's go ahead and talk a little bit through our asynchronous code, right? Let's look through our code here. and we want our asynchronous code to start looking synchronous, right? If we look, we got this chaining, and this is starting to look a little synchronous, meaning like we're going one after another, right? Looks like we're going one after another, right? It looks like it's working one after another. Boom, boom, boom, right?

And so we're getting there. We're getting to this point where our code that is really asynchronous in nature, right? We're handing this stuff off to the browser, the web APIs, all that goodness is happening. And then those responses are coming back. And now we can start handling these responses in a way, right? Right? In a way, right? In a way that starts to look a little synchronous, right? Like the normal JavaScript that we would write one after another. And with the beauty, that is some of the newer JavaScript, right? The newer JavaScript that's coming through, like the ES8+, like the ECMAScript 28+, 2018+, we started to get this wonderful thing called async await. And this async await made our asynchronous code start to look a little synchronous, I started to make it look like the other JavaScript that we know and love. And it's just a way to handle these asynchronous responses. Remember, we're doing stuff that JavaScript shouldn't be able to do. That gets handed off, right?

That gets handed off, and that gets handed off to the browser. The browser starts to do stuff with it and then respond. So we need a way to handle those responses. We saw that callbacks can lead to callback hell. We saw that promises with the den chaining, it's okay, but it doesn't really look like good JavaScript. And so we got a lovely new async await syntax. DigitalFendi, hey, thank you for the posture check. Let's see, let's get in here. Oh, all right, there we, oh, oh, cool. All right, there we go, beautiful. And the interesting thing about our async await is that's just syntactical sugar on top of promises that makes our asynchronous code easier to write and read afterwards. If we had to keep track of these like promise chains, like yeah, it would work, but it don't read too good. Right, don't read too good. And so I want to use something that makes our code easier to read and write, but it's still just we have to understand and promises underneath the hood after all. And so we have this lovely syntax where await waits for an asynchronous process to complete inside of an async function.

But await waits for an asynchronous, like something that's gonna take a while to complete as long as it is inside of an async function. So let's take a look. Here we have the same functions that are promises. All right, we have the same functions that are promises. And then, we have this lovely async function that just works the same as our promise chains. Uh-oh, oh, oh, oh, look at this code, folks. Look at this, this, oh, now we talking. and look at this code folks. Oh, look at this code. Ooh, cool. All right, we have an async in front of our function, right? We have async in front of our function, and then we can just tell our house one to await. And once it's done, we'll store whatever response we got back inside of house one wait. Then we have this next bit of code here, house two await, whatever happens gets stored in house two wait. And then we have house three wait, whatever gets stored there gets put in house three wait.

And then we do our console log. So let's actually run that code. Let's run this code. Let's comment up our disgusting promise chains here. Ugh, go away. And then let's come down here to the same functions, right? The same functions, however, with our lovely async. Oh, look at that. Our lovely async await syntax. Let's save it. Let's go back to the browser. Let's run it and let's see what happens. Taking our time. We're waiting. All right.

Ooh, take your time. In one, two, three. Hey look at us go so even though even though house one takes a second house two takes five seconds house three takes two seconds like even though we should think it should be one two three with this lovely async await syntax we can have all of our asynchronous stuff and a nice, beautiful rapper that looks synchronous. Wow, ooh, looks so good, folks, looks so good. But now you're like, Leon, come on, I need something real. Give me something real. Leon, you're talking about getting paid, you're talking about, you've been talking about houses. is give me something real, give me something real, all right? So we've built API requests out the wazoo, right? So let's take a look at an API request using the async await syntax. Boom, here you go, folks. We have the lovely async in front of our function, and then that means we can use the await syntax inside of that function. So here we're going to await the fetch. Whatever comes back, right? Whatever comes from this resolution, right?

Remember, this is still what? Underneath the hood we're still doing a fetch. Fetch still returns a what? It still returns a promise, right? So we know that this is going to resolve and whatever gets resolved from this promise is going to be stored in R E S. Then we await the lovely making sure what we got back is JavaScript, right? We have this lovely, the thing we saw before with our, with our normal promise chaining, right? We're just making double, making it JavaScript, making sure that we got the thing that we care about and then that gets stored in data and then we console log the data so we go from that nasty ugly fetch with the then chaining then chaining to this beautiful async await syntax where our code actually looks like it's synchronous javascript but all of this right all of this all of this asynchronous stuff right that's happening right It can take its time, but our code still looks like regular JavaScript. Now, here, this would work, but right now, are our errors caught? Nope. So with async functions, we got what? We got two things. With async, we got two things. Yeah, folks did the reading tries and catches. So your homework is to add a try catch block to this asynchronous function.

I want you to try, I want you to get in here, get your hands dirty, add a try catch block, because we know that a lot of things can go wrong with a fetch, right? There's a lot of errors that could happen. And so I want you to come back and make sure you dig through the reading and add a try catch block to it so that you can catch errors. Yeah. That's part of your homework. That's something I need you to do before Tuesday. So I need you to practice using these async functions. And so try adding a try catch to this. Cool. All right. Back end baby. We built up to it. We were able to get to what we came here for. we built up to this idea that JavaScript was running in the browser. Since JavaScript was running in the browser, it had access to all these web APIs, but these web APIs, they're handling asynchronous stuff, and JavaScript is not an asynchronous language.

So we needed a way for us to hand off those things, and then be able to hear the responses that came back from the browser. We saw the first way of dealing with those responses that was callback hell. Then we saw a newer way to handle it, which was promises, but promises led to promise chains. And then we have a bright new future with async await, where our asynchronous code starts to look like synchronous JavaScript. It's super readable. We can see what's going on and it sets us up for success. But now we got all that on the table. We can move into the back end. Alright. Now I have a question for you as we move into the back end. Does JavaScript. Have access to the DOM natively built in? Hmm. Nah. Mm-mm.

It doesn't. Nope. Mm-mm. JavaScript needed web APIs to handle all the asynchronous stuff and a bunch of other stuff in the browser. Like JavaScript just didn't come with the ability to handle all that asynchronous stuff. JavaScript didn't come with a bunch of stuff that the browser gave us access to, right? Right, so we didn't get it. We got it because JavaScript was sandboxed in the browser, meaning that JavaScript was running in the browser, and since it was running in the browser, it got access to all that stuff. So JavaScript, we could think about it as running in this environment, as running in this sandbox, and it only has access to the stuff that's inside the sandbox. It only has access to the shovels and pals that are in the sandbox with it. Now, let's think through this for a second. JavaScript is running in the browser. I have a question for you. Does JavaScript have access to the files on our computer? No.

Why would that be a really bad idea if JavaScript had access to the files on our computer? Yeah. Any website you go to could then like look at the files on your computer. We wouldn't be able to use the internet. So JavaScript when it's running in the browser does not get access to the files on our computer, because that would be a pretty big vulnerability. That's what I mean by sandboxed. JavaScript is running in this sandbox and it can only play with stuff that's in the box with it. It doesn't have access to things like on your computer. It's stuck running in the browser environment. Now, the browser gives us lots of stuff to play with. It gives it access to the DOM. It gives us access to fetch. It gives us access to all these other APIs that it can use. but when JavaScript is running in the browser, it is sandboxed. It can't get access, right?

It can't get access to all the files on your computer. And that's a really good idea because we would never be able to use the internet if every website we went to, right? If every website we went to, JavaScript could break out of the sandbox and play with all the stuff on your computer. That would suck. We would never be able to use, we'd never be able to use our computers ever again on the internet. Now, since JavaScript is sandbox and it can't access the things on our computer, every once in a while someone figures out how to get out of the sandbox. We call those zero-day exploits. They're exploits that figure out a way to escape the sandbox box and get access to things on your computer to get access to things that it should not have access to. And so I'm here to tell you today, if you ever figure out one of these exploits, send me a DM. I don't ever check my DMS, except for this. You send me an exploit. Well, I'll make you rich. I know the people to talk to will get paid. I'll split it 50, 50, right? We'll split it 50, 50.

I know who to talk to. You figured out, you come talk to me, right? and we'll get paid, we'll go to Cabo together, we'll do some crypto gambling, we'll have some fun, right? Because these are very, very, very rare. It's very rare that we figure out a way to break out of the sandbox because that could have devastating effects. So when you figure it out, come to me, I'll put you in touch with the right people, we'll split it 50-50, go to Cabo, do some gambling, have some drinks, we'll figure it out. Cool? All right. Somebody offered me 60-40, all right, go ahead, I'm getting screwed, you trust me, this is, you trust me, come on, this is what this has all been about, this is just get your trust so that when you find a zero-day exploit, you come to me and nobody else, that's it. Don't you want to go ride jet skis, exactly, come on now, you trust me, I'll make sure get paid. All right. Now, this makes sense. And this idea of the sandbox makes sense because JavaScript is a language that can only do what the hosting environment allows. When we run JavaScript in the browser, it gives us access to what? When we run JavaScript in the browser, what does it give JavaScript access to?

We get access to the web APIs. We get access to the DOM. We get access to fetch. We get access to all the stuff that we get by only running JavaScript in the browser, like the DOM. Cool. So JavaScript is a language that can only do what the hosting environment allows. Now, let's think for a second. If we're trying to get to backend development, what do servers actually need? What do servers do? What do servers do? They serve, yeah. So they serve up files. Now, do these files exist magically like in an ether somewhere? where do these files exist? If the point of a server is to serve, where do these files exist?

In some sort of storage, right? It needs, the files have to exist somewhere. So they're probably on disk somewhere, either on a hard drive or an SSD. Like the files have to be somewhere. And so they're probably on a hard drive or an SSD somewhere. Like the files have to exist somewhere on the computer. They're not magic, right? And then servers also do what? They serve, but what does that mean? What does it mean to serve? Yeah, it can hear requests for those files and respond with those files. So if it can hear requests and respond, what else does it need access to? It needs access to the internet, right? If our servers don't have the ability to listen to network requests, like if they don't have access to the internet, they don't have access to a network, right? It doesn't have to be the internet, it could be like a local network as well, right?

If it doesn't have access to a network, then it can't hear the request, it doesn't know what to serve you. And if it doesn't have access to the disk, right? If it doesn't have the ability to get the files off the hard drive or the SSD, right? Then it can't do its job. So our servers are gonna need access to the disk, either hard drive or SSD to get the files that they are then gonna send to you, right? And our servers need to be able to hear what files you want and then respond with those files. So it needs access to the network. Now, let's ask a very serious question. Does JavaScript have the ability to access the hard drive or the SSD on our servers? Does JavaScript have the ability to listen to the network? Does that come out the box with just JavaScript the language? No, JavaScript doesn't have access to the disk. JavaScript doesn't have access to the network. That would be a really bad day if just regular JavaScript had access to all that stuff because then it wouldn't even need the browser to do it, it could just do it itself. So JavaScript out the box does not have access to the disk.

It can't get our files off of our computers. It does not have access to the network. So it can't listen to requests and generate responses. But what if, what if folks, What if there was a hosting environment that allowed JavaScript to have disk access and network access so that it could hear requests, it could generate responses, it could pull files off of a hard drive or an SSD, this is a warning. What if there was a hosting environment where we could run our JavaScript and that JavaScript would have access to the disk? It would have access to the network. Well... Hey does this work? Let's go! That's Node baby! That's Node! That's Node! Let's go! Oh, let's go. All right, so we're super excited.

We're super excited. And we go, and we go to the node website, nodejs.org. We go there and we see, all right, we're super pumped. We get it, right? Node's gonna give us access to disk and network. We're really cool, but we understand like JavaScript was running in the browser. Now we can run it in something that gives us access to the disk and network and we go to the website and the website says this JavaScript node.js is a JavaScript runtime built on a Chrome's v8 JavaScript engine the disrespect we got all excited we go to their website and they give us this Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. All right, let me break this down for you. The same shit that lets you run JavaScript in the browser can now be used to run JavaScript on servers, desktops and everywhere else pretty much. And so that's Node, right? the same shit that lets you run your JavaScript in the browser can now be used to run JavaScript elsewhere. And so we can go through and we can kind of edit this a little bit. Notice a JavaScript runtime, we can just say, like is an environment built on top of Chrome's V8 engine. Well, Chrome's V8 engine, is this like the stuff or the shit that enables JS to run in the browser, right? So we can just give it a Crosier engine.

The ship that enables JavaScript to run in the browser can now run everywhere else. So, Node is just an environment that uses the same stuff that the browsers used to enable our JavaScript to run. So notice just an environment where we run our JavaScript that uses the same stuff that the browsers were using. But now we can run it on servers, desktops, everywhere else. That's like, why can't they just say that? Why can't they just like the browser, right? Right. Just like, just like the browser. He has access to a bunch of stuff. Well, well, node gives us a bunch of stuff. I can't think to say that. Be so much easier. That'd be so much better. All right. So let's talk about how Jeff Goldblum saved the world real quick.

How did Jeff Goldblum save the world chat? Bub, exactly, binary upload boom. So Jeff Goldblum reversed engineered the alien's code, wrote a computer virus that took down their shields, we nuked America, right? So Jeff Goldblum was able to write that computer virus because they broke down the code all the way to like the zeros and ones, like the actual code that runs on our actual hardware, right? Our computers don't actually run JavaScript, right? That JavaScript gets broken down into something that the computer can actually understand. The thing that's doing that, like breaking down is called the VA engine. That's it. So in the browser, the VA engine is the thing that takes our JavaScript and breaks it down into something that the computer can understand. And that engine not only does it in the browser, but the engine also does it for node. So the thing that takes like that really easy to understand JavaScript and breaks it down into the code that the computer needs to understand, that's the VA engine. Now, some people are saying, is that a compiler? Sort of. it does more, right? It does like the compilation stuff.

It also does like garbage cleaning, like all this stuff that like doesn't come with JavaScript that we need. The V8 engine kind of does all of that. When we get to class next week, yeah, we'll learn more of the like the technical jargon around all this. So save things like compiler, transpiler, interpreter. Let's save that to next week when we get to like the heavier portions of how Node is actually working. But yeah, it's all the stuff that's gonna take our JavaScript and break it down to something that the computer can understand, it does all that heavy lifting for us. The cool thing is, just like the browser's web APIs, Node comes with a bunch of stuff. So JavaScript is running in the browser and it got access to the web APIs. Now we're saying, wait a minute, let's take JavaScript and run it in Node. That means we get a bunch of stuff. We get all the stuff that comes built in with Node. And so we have all these libraries or modules and these modules are just collections of functions, basically, and so we have an HTTP module, which is a bunch of functions that have already been written for us that enable us to talk to networks like to hear requests to generate responses to, like, listen to the Internet, basically. And so that just comes built in with node, just like the browser came built in with like fetch and the DOM, node comes built in with like HTTP access, like access to the internet, access to the network, right? Also, it comes with the FS or the file system module, which is just a collection of functions that enable us to access the file system. Remember, a server needs to hear requests, generate responses, and to get those responses, is we need to like get files off of our server and send them to you.

And so JavaScript has no way of doing that. But when we run JavaScript inside of node, we get access to the network. We get access to the file system. And we also get access to millions of other packages, AKA groupings of other custom modules or groupings of other custom functions have already been written to us through things like NPM, Yarn, and other package managers. So the cool thing is we were running JavaScript in the browser, but now we can run it in Node and get access to things like the network, get access to the file system, and access to millions of other things through things like NPM. Now we talked about the V8 engine doing the heavy lifting, but the reason why Node is pretty be fun and cool to work with is that underneath the hood, it's really just using C and C++, which means it's super fast, right? It's really fast, maybe not the fastest, but it's pretty damn fast. And we get access to all this stuff that's been done for us already. When we run JavaScript, it's being broken down and using all of these like fancy stuff that's been written in C and C++, so we don't have to. So we don't have to worry about how we're handling the network access how we're handling accessing the network We don't have to figure out how we're actually like doing any type of compilation or garbage collection We don't actually have to worry about the event loop or any that stuff that we're gonna get to next week It's all being handled for us and that's the beauty of running our JavaScript inside of the node environment We get access to all this stuff. That's super fast That's written in C and C++ and we get to get this takes care of all the heavy lifting for us right We get to use the JavaScript that's readable We get to use the JavaScript that we feel comfortable with the JavaScript that's worked in browsers for years and years and years So we get to take all that syntax all that knowledge all that learning and run it in a new Environment that gives us access to new stuff now we get access to the network We get access to our file system. So the code that only used to run in the browser can now run on our servers and we get the benefit of only needing to learn one language to both write code on the front end, in the browser and the back end on our servers via node. Cool. I think so too, Pony. I think it's pretty cool.

All right. Now there's a lot of stuff here. There's a lot of stuff here. We can talk about the call stack. We can talk about the callback queue. We can go deeper into what the heck are node modules, the event loop, all that stuff. Tuesday, I got you. Don't worry, I got you. See some of you are like, ooh, I wanna learn more about that. I got you. All right, so part of your homework over the weekend is to set up your environment, aka set up node. Thank you, Benito. So we want you to set up Node. For a lot of folks, installing Node can be a little bit of a journey, but just save yourself some pain and just go to the Node website. That's the link in the slides.

And you don't do it right now. Do it when you have some time, if you haven't done it as part of the reading. And you're going to install Node just from the website. Just trust me, just do it from the website for the first time. You can use your package managers later on. You can use your node managers later on. You can use your home brew or whatever the heck later on. But for the first time, trust me, across thousands of students, I've seen the most unbelievable nightmares happen as people try to set up their, their environments, it's just easier if you just click the button, just, just for this time, if later you want to set up MVM, all that other fun stuff you can, right? Yeah. So you can, but for just click the buttons, do that for me, please. All right. but I love the pain. It's all right. You won't recognize the pain right away. It's slow.

It comes on when you least affect it. Cool. All right. So you see here that we see something interesting. We see this LTS and we see the current. And some people are like, well, Leon, what do I use? Well, let's talk about what the differences are. Typically there's three, what we call release schedules, the LTS or long-term stable, the current, and then a lot of projects have a nightly version as well. And I think this is actually a little bit, my photo's a little bit old, so I'm going to click this. Hopefully it gives me the photo. All right, here we go. Cool. This is, my photo was a little old. Here's the newer one. So what you can see here is the developers that build Node, like build the actual, like build out the node project.

They give a schedule here of the different versions and when they're actively being developed and how long they're gonna support them for. So maintenance means that like, we know that you've built your projects on node, here's how long we're gonna support that version for. So if any security vulnerabilities crop up, we will handle them. You can trust if you're building on this version, here's how long that version will be supported for. And so if you are on an engineering team and you're trying to make a decision, like you're building your app from scratch and you're like, all right, what do we start with? You have a few options. You can see that the current LTS is 16 and it is still in active development, but that will end in October. And then it will go into maintenance mode all the way until April, 2024. So if you were to build on top of node 16, you would have all the way until April, 2024 to feel really confident, right? To feel really confident. Hey Mets, to feel really confident in like your version of node working well, all the security vulnerabilities are being patched, everything. But if we kind of look, 18 is looking pretty good right now. 18 is looking pretty good right now because 18 is going to be in current development. So there's gonna be some new stuff that are coming out. So some folks don't like using the thing that's currently being developed because they're afraid maybe that some newer features might come out and maybe they might not be ready for prime time.

But you'll see that the active window will be a lot longer. and then the maintenance window takes you all the way into 2025. So as a team, you have to make a decision. Are you going with the current LTS? Or are you going with the currently being developed version? Or are you a maverick and gonna go with a nightly? Nightly is like all the newest features, like your shit will probably break. And the cool thing is like a lot of other software uses this type of schedule, like Chrome. Chrome has a stable channel, which most people are using. They have a developer channel where you get all the new features, but some stuff might not work. And then they have the Wild Wild West, which is the nightly channel, where things just like break, right? But you get to see all the cool stuff first. And so I recommend that if you are kind of going through this course, that you have two choices. is you can go with LTS or you can go with 18. You're not gonna lose anything if you went with either or all of my code works with 16 going forward.

So it's up to you if you wanna start with the LTS or the current, I'm using 18 right now, right? So if you want it to be exactly like I have, you would use 18, but you can't go wrong using either of these. Cause I know a lot of people kind of already set up their environment. If you're on something lower than 16, you got to update though. All right, now let's take a look at a simple server. Let's take a look at a simple server. Here is my simple node server. You can see here that I am requiring the HTTP module and that HTTP module is gonna give me access to the what? What's that HTTP module gonna give me access to? It's going to give us access to the network, exactly. How about the FS module? What's that going to give us access to? It's going to give us access to the file system, beautiful, the file system. And then down here you can see that I am using the HTTP module and what the heck is create server? What is that?

What is create server just by looking at it? What is create server? It's a method right that means HTTP is an object and create server is a method and so we're gonna still see like JavaScript is still JavaScript, right? Even though we're getting all these extra goodies, like we're getting access to the network, we're getting access to the file system, right? It's still JavaScript underneath the hood that's enabling us to do all this stuff. So we don't throw the baby out with the bathwater, right? We still have all the same goodies, we just get extra added stuff here, right? And so we can see that createServer is a method that is part of the HTTP module, right? Built into this HTTP module, you could see all these like really wild functions that do all the heavy lifting for us. Just like the DOM did all the heavy lifting for us, just like Fetch did all the heavy lifting for us, this module has all these methods built into it, right? That has all these methods built into it that enable us to do stuff. And we can see that one of the methods literally helped create the server that then listens on a specific port. You could think of, you could have multiple servers running on one computer, but they could all be listening out different windows. And so this is the window I'm listening out onto, right? Right, I'm listening to the 8,000 port.

And all this stuff is just using the core modules. Eventually we'll use things that make the syntax prettier, that make it easier to read, but this is like raw node, right? We're just using the base HTTP module. We're using the base file system module. And what we're doing is we're saying, hey, create a server that's listening on port 8000. When it hears any request, when it hears any request, we're gonna read this file, this HTML file, and we're gonna respond with it. We're gonna tell them to expect an HTML file. We're gonna send that HTML file to them. and then we're gonna tell them that our response is done. All right. And so let's actually see this running. I'm gonna go to my code here. I have this lovely node intro demo, and I have two files here. I have my demo.js, and I have my demo file.html. Now to run this server, I need to tell node to run this file.

So I'm gonna open up my terminal right here in VS Code, and I'm just gonna say node. Well, actually, let me make sure I'm in the right folder. So let me do an ls. I need a cd into node-intro-demo. And then I'm gonna run my demo.js file. So node-demo.js. All right. We can see something here. Hold on. Let me move my head out the way. We can see something here. When I read node-demo.js, what happened? What happened right here? I didn't get my prompt back. I didn't get my REPL back.

You can see that it hasn't given me the ability to enter in any more commands because my server is running. I better go catch it, right? My server's running. So I can see that it's running because I haven't gotten like my REPL back to type more stuff. So it's running and if I go to the port 8,000 so when we're running servers on our machine We're pretty much always gonna use localhost 8,000 is the port I'm on and when I go there, I see hello world Hold on All right. We went to port 8,000 and it sent us back this hello world file. However, look, look, look, look, let's go back. Let's chill the server. You can see I have my REPL back, right? Like I can type more commands if I wanted to, right? And so is my server running anymore? Nah. So if I go back and I refresh, yeet, it's gone. So this is legitimately a server that is serving up, right? It is literally serving up our HTML file.

If we go back and look, this demo file that HTML just says, hello world. That's what's in there, right? How did I turn it off? I just did control C on my computer, control C. That's what gives me back my prompt here, my REPL, right? So now I can start my server. hit enter we can see that it's running if I come back and I refresh oh boy I'm serving up an html file right I'm serving up an html file right we are running javascript files in our node environment which is giving us access to the network which is giving us access to the file system. I'm able to grab files off my disk. I'm able to serve them up. I'm listening on a specific port. First try. And so with this very simple bit of code, this is your warning folks, with this very simple bit of code, using what Node gives us access to, getting access to the network, getting access to the file system, but just some simple code where we're saying, Hey, whenever we hear a request, this is the response we're sending. in. Hey, does this work? Let's go.

You are all now newly knighted full stack web developers. Just go out there and do well with this knowledge. That's all it takes, you're backend now, baby. Let's go. So now you are developers that can write front end code and you're developers that can write backend code that literally legitimately runs on a server. You are now full stack web developers. The secret is I could not write this from scratch. I copy and paste it, right? Maybe by now I could probably do it. But most of the backend is really kind of like copying and pasting stuff in the beginning until you get comfortable with it. So you can't be like, I don't know how to do this yet. I don't even know how to do this yet. I've been doing this for years. Right. So I don't want you to like, look at this and be like, ah, I ain't gonna ever get that now.

There's nobody expects you to have this memorized. Like that would be a fool's errand. and we're going to add other stuff on top that makes this process easier, like express, that makes it cleaner, that makes it easier to read, easier to write. But in the beginning, this is like I'm saying, this is raw. This is just using what Node gives us at the base level, the HTTP module, the FS module, that's it. And we can use that, right? We can use that to build the simplest of servers and become full stack web developers. Let's go. I'm hella proud of you all. This is a long lecture. You stuck it out. You learned a lot of wonderful code. You've been here for a few months now, but now you're full stack web developers, baby. Update your resumes, update your LinkedIn's, tell your mama I'm full stack, baby. Let's go.

Congratulations. You deserve it. You really do. Jay says, welcome to full stack, everyone. Hey, thank you, Jay. Let's go, congrats, everybody. All right, now, we got some wonderful stuff this evening. We're gonna see on Tuesday a more complex backend. We're gonna spend more time talking about things like the event loop and what Node is actually doing to help us. How does JavaScript really run in the browser? or how does it really run on the server, right? And then we're gonna use that to build a more complex backend, baby. We're gonna get that more, look at that more complex backend. We're gonna get that going. And we're gonna talk about a lot of fun things.

So this weekend, I need you to do some stuff. Please don't run away just yet. I want you to do some stuff. This weekend, I need you to start taking the bank seriously. Come on now. Look, it's my birthday. I ain't running away yet. Come on now. I need you to start taking the bank seriously. please Start the bank You need to complete your professional links as well. I opened up the submission today So I need you to go through and keep that keep that coming through make sure you get all the stuff in here and then I need you to Don't worry about these two, but I need you to go through and get node installed. I need you to come back and Run this simple code make this work I need you to go back through the slides and I need you to ask questions on discord. Right. I need you to ask questions on discord. You do all those things, you're gonna have a good weekend.

There's a little bit other bit homework on the discord, but those are the big things I need you to do. Please start the bank. Please start looking at this code. Get node installed. Make sure you finish up your professional links. We're going to the next week hard, right? We're gonna, we're gonna, this, this, this back end stuff's gonna keep growing. Gonna keep taking off. Let's see where we're at. Hold on one second. One second, I wanna see one other thing before we go off and do our... Yeah, I just wanna see something else here. Really important stuff to talk about real quick before we leave. I gotta clean it up. Some of y'all don't know how to read the prompt.

Let's see. Hold on, there's a lot of stuff. Oh, crap. All right, I'll save this. Holy smokes. All right, nevermind. I can't clean this up fast enough. I was going to tell you how much money we brought in from, from our, from our freelancing, it's a lot, but there's a lot of like, some people put like USD or some like text in there, so I got to, I got to clean it up a little bit. Uh, so I'll, I'll, I'll announce on Tuesday, how much money, Oh, maybe I'll do it during office hours. Remember Sunday, we have office hours. We're talking about how much money we brought in from freelancing. It's a lot of those. I'm seeing hundreds and hundreds of responses so far of folks that got freelancing clients. This is wild stuff that I'm looking at right now. But let's go ahead and end on a high note.

We always like to do a raid. So let's go ahead and send some love and positivity somebody's way. Let's see. We haven't been to True in a minute. Oh, Rufio's on. Let's go to Rufio. All right, let's go ahead and do our raid. Remember, if you haven't followed already, my birthday wish was that you give them a follow on both Twitch and Twitter. And let's go ahead and raid Rufio. All right, folks. Have a wonderful rest of your day. Have a wonderful rest of your evening. Thank you so much for the birthday wishes. Thank you for everyone that checked in on me and my wife. I really appreciate you all.

Have a wonderful rest of your day. Have a good weekend. I will see you on Sunday. And we're back at it with Node, folks. I can't wait to keep going deeper into the back end. Let's raid. Peace YouTube.

End of Transcript