Introduction

Hey. Hey, does this work? Hey, good morning. Good afternoon. Good evening. No matter where you're coming from. Hope you all are doing well. Welcome back for another week. Let's go what is up everybody yeah yeah let's go oh boy whew i saw rascal i saw you coming in with the raid okay rascal i see you with the 20 okay i see you welcome in everybody hope you had a wonderful weekend uh hope you are ready to back that back end back up because We're going deeper folks got a little bit more things to cover got a little bit more things We're we talked about some big words that last week would have been disrespectful But tonight or we're gonna go a little deeper. We're gonna go a little deeper. We're gonna talk about the event loop We're gonna talk about the call stack. We're gonna talk about queues We're gonna talk about live event live above. We're gonna talk about see in c++ API's what? And there's a lot of big words, but I promise they're not gonna be disrespectful. You're gonna understand it by the time we get through tonight, you're gonna know more than most professional JavaScript developers.

I've worked with a lot, I don't wanna say most, but a lot of them. I've worked with a lot of JavaScript engineers that underneath the hood, they don't really know what's happening. Tonight, you're gonna understand what's happening underneath the hood, both in the browser and when it comes to Node. Then we're gonna take the project we started last week, we're gonna take it even further. We're going to see how we can build out our own API. A lot of, a lot, a lot of heat packed in to tonight's class. So I hope you're ready. We're going to, we're going to take our time though. We're going to, we're going to revisit a lot of this stuff. We talked about last class to get warmed up and then we're getting into the fancy JS terms that we got to learn about. I missed last class. Should I go back tonight? Nah, I think tonight will be enough review for you to hang on. If you need a little bit more detail go back and watch the last class is already on YouTube Exclamation point YouTube you got it there Welcome everybody. Oh Boy we had a lot of folks some some some some ogs in the crowd tonight.

I saw some folks coming back I see y'all what's going on everybody? Hey, all right, so we got a lot of fun stuff to get into we're going to as As always, start off with some questions. I always like folks to be able to get in here. The question of the day, though, we haven't done a question of the day in a minute. The question of the day, would you rather be the funniest or the smartest person alive? Funniest or smartest? Put fun or smart in chat for me. Fun or smart in chat. Funniest or smartest? I don't know. I think, like, the funny thing is, I think to be really funny, You got to be kind of smart too, right? Funniest we're seeing a lot of funny. It's actually pretty balanced funniest smart. Okay. I see y'all I'm kind of good group here.

I mean we're all here to be we're all here because we want to be soft Well, we are software engineers, but we're all here to learn more engineering skills So I think smart kind of winning out on this one is is pretty given Uh, but we got a good balance. Okay. I see y'all I see y'all I think at the end of the day I See the perks of being the funniest. I think it's easiest to go about life being the funniest There's a clear path being the smartest. I don't know Smart is lonely This is a tough one because if you would have asked me before I was like smart all the way But yeah, I'm gonna I'm gonna stay with smart. I'm gonna say what so I see the value of being the funniest I think that's a way better. I think that could be a better life, but I'm going to go with smartest. Maybe, maybe there's some room to do some good by being the smartest person. That's why it's the way I'm going to go. Ignorance is bliss. Hey, already folks, as always, like to give folks a few minutes to get in here. I know some of you are running late from work, so no worries. You got some questions, folks. Let's get them in while we give folks a chance to get in here and we're going to get into it. Lots of heat to get into tonight, folks.

What am I sipping today? I'm sipping just regular water, but it's in my kombucha cup because I was running a little late and I just dumped water into it because it was empty. Do I like sushi? No. I'm vegan, so a lot of sushi is off the table, but the vegan sushi, not really my jam. You Thought some chaos new I'm off If I haven't had time I haven't had time I'm hoping this weekend I get because I I'm not gonna listen to a piece man I got to sit down and I got I got a I got to listen to it the whole way through Right, and so if I don't have that time, I'm not gonna do it So hopefully this weekend I get a block of time where I can listen to it the whole way through But yeah, it's it's pretty high up on my priority list Ake has said, Hey, I just found your YouTube channel. I'm super far behind. I'm a designer. I've always been really intimidated by coding. Love your approach and would look forward to working through your course. A, you're not behind. You're part of the Ketchup Crew. And so if you've done exclamation point 100 devs here in chat, I'll give you everything you need to know about 100 devs. You join our Discord. You agreed to the rules.

You join 100 devs on Discord. You got to click some emojis. And when you do that, you'll see the Ketchup Crew. That's your group. You start through there. You be able to work with others as you work through the material at your own pace So there weren't none. Nobody's behind here. We're all in the same roller coaster Some of us are just on the front cars and a few of us are further back Wife is doing well. Thank you for everybody who keeps asking. I appreciate that Oddly send a mod mail and we'll get that info your way We're a little behind on mod mail right now and ask Leon, but I'll be caught up hopefully today because we're going to, we're going to end a little early today, uh, cause we're going to do some, some, some working together and, uh, I'm going to take some of that time to catch up on, on mod mail and, and, and ask Leon. Are we allowed to use modules for a hundred hours project? Absolutely. Yeah. Nickelodeon, Cartoon Network, or Disney Channel? Nickelodeon as a kid, Cartoon Network as an adult.

Few more questions and we're gonna get started. Honey said, can we still join the bootcamp? Absolutely, do Xmation Point 100 devs here in chat. It'll give you everything you need to know and how to get started with us. I wasn't able to follow for the past month through the various reasons. I heard about the clean slate. Can you elaborate? Yes. So we, starting last week, we offered a clean slate, meaning if you missed a few check-ins, if you missed submitting some homework, that would no longer be held against you. Your slate is wiped clean. You have to start this week, however, checking in, making sure that you're doing your Code Wars, your Anki, Make sure you're submitting all the homework going forward. And so if you're if you're a little behind, that's okay Slate is wiped clean and going forward. You're good to go Is it still possible join the LinkedIn group Yep, go ahead and just join and as we had time we add folks So I probably do like once a week now now we're past that class I'll do it like once a week to add more folks Where do you submit homework? The links are in the discord message for today. And they're also in the slides.

Can you recommend any good links for starting a podcast? I don't have any, but if you find them, let me know. Cause we got to start the 100 devs podcast. How much money made from freelancing? Oh, I can't release the number yet. It's really high. It's it's it's kind of like I would like what it's really we got we got to do it, right? We got we got to announce it somewhere. Maybe like Twitter first or something like that, but it's it's it's way more than I was expecting So if you haven't filled out See me see mama if you haven't filled out the client form fill it out I wanted I wanted to give folks a week to catch up to get their stuff into that form But it's really high With Code Wars, I keep missing little things I can't figure out, it's so demoralizing when I look at the solutions. No, that's that's how you do it. There's no magic way that you learn, like there's just no way that you know how to solve some Code Wars. You've literally never seen those, those, those tools. It's like, it's like showing up to a job site and never having seen a hammer before. and everyone keeps handing you nails and you don't know what to do with them because you've never seen a hammer. You can't fault that person for never seeing a hammer before but once they see a hammer, they better know what to do with it going forward.

That's the same thing with code wars. You're gonna have so many tools on your tool belt that you've never seen before. You can't get down on yourself for not knowing what the tools are, but once you see them, once you see that tool and that solution, then it becomes your goal to never forget how to use that tool in the future. And so when that same pattern comes up again, right? When that same pattern comes up again, you better believe it's hammer time. Exactly. You can't expect a fish to know how to climb a tree. Well, fish is a really weird word. It's a lot of stuff that we think are fish that are all different things. There was a really cool thread on Reddit the other day that was like, what's your favorite animal fact? And that there is something about like certain whales and dolphins have hip bones that support walking And so the belief is that they like started in the water Went to land and then said land sucks and went back to the water I don't know. Maybe they could climb trees back in the day. Who knows? Also sharks are older than trees Let's hold on. Let's think about this first Sharks are older than trees Sharks are older than the rings on Saturn.

Let's think about that. Let's also think that we kill what 10 million sharks. Oh, there was something weird. It's like 10 or a hundred million sharks a year. And, uh, only 10 people a year die from shark attacks. So we have like a kill, like a Katie ratio of like 10,000 to one on sharks. But they're older than trees. This is what you came here tonight for, folks, right? This is what you came here for. You thought you were gonna come here to learn about the event loop, JavaScript, but you got got. It's all Shark Facts. This whole rest of this class is Shark Facts. 100 Dev Shark Week, there you go. I'll link the thread in the followup message to today's class. It was really cool.

There's a lot of animal facts that I didn't know that were pretty dope Cows killed 20 people a year. I would think it would be way higher cows are reckless All right, I think we got our questions in I think everyone's here Let's get into it. If you haven't checked in Please go ahead and check in we need to exclamation point check-in that does nothing here in chat But it does give you the link you click that link you like and retweet the the post it helps people find us We got so many new folks joining each and every day It's amazing to see and it's because of all the work that y'all do liking and retweeting Liking and commenting on YouTube really really helps with so many new folks Hundreds and hundreds of new folks are finding us through YouTube each month So I appreciate everyone that gives the new videos a thumbs up lets them play in the background It really does help the algorithm so and as I always said like your slate has been wiped clean You have to start checking in now if you want the benefits come end of program beautiful Everybody thank you for checking in Office hours this Sunday. So this Sunday we're gonna have like a longer office hours. We did the power hour this Sunday About last Sunday with this upcoming Sunday. We will have like a more traditional office hours We're gonna review a lot of the code that we do today So if you go through today and there's some things that you're still kind of like hung up on that don't make sense Come to Sunday's office hours. We're gonna get through it. We're also gonna do a little car practice I can't I can't do the Friday this Friday to do car practice So we do a little car practice during office hours cause action result for your bank questions So if tonight some of the code is a little rough come back Sunday You have some questions come back Sunday And if you want to see me work through some car cause-action-result for some of the questions We'll do it live come to office hours on Sunday office hours start to become a little bit more important going forward There's only so much stuff I can cover during two weeks two weeks or like two days a week for class time and so I'm gonna put a lot of stuff into office hours just as a little a Little bit more time to catch up on stuff a little bit more time to revisit some ideas and concepts that need to sink in Well We must watch our class on freelancing we have a whole class on it that'll kind of answer those questions Cool Networking I need you to start networking again folks. We're back in it. All right. We're back in it We're back in it. I need you to start getting those those coffee chats again. I'm asking just for one one cup Weency, weency, one itty bitty, one itty bitty coffee chat. Just one, just one coffee chat, please. Just one, just one.

Oh. Carth flexing, got one today and one tomorrow. I see you, I see you, Carth. Got one today, got one tomorrow. What's up, let's go, congrats, that's huge. You got me said all right. Thank you. Thank you decaf, a decaf coffee chat. What's a decaf coffee chat? What do we think? What would that be? What would be a decaf coffee chat? Is that, is that like with the teeny weenie one? I had one today. It was awkward.

Those are our decaf ones. Yeah. Our decaf coffee chats are the ones that just that are slow, that get a little awkward, those are decaf. That's the new tech. That's the new term now. When you're on discord and somebody is like, oh, how'd your coffee check? Oh, no, it was decaf. It wasn't it. It wasn't it wasn't a full bodied coffee chat. It was it was definitely decaf. There you go. Create new words out in the streets. One coffee chat, please, and it better not be decaf. All right, use the sheet. Please be keeping track of the people you reach out to, keeping track of these coffee chats.

Eventually you're gonna start putting time into your hit list and that's all going in the sheet. If you don't have it, exclamation point sheet here in chat, click the link in the slides. If you need the slides, you can always do exclamation point slides and you have access to them. Caesar got three chats this week. Hey, turn up. Cool, make sure you're using the sheet, folks. Make sure if you haven't done the checklist yet, you're behind, you're behind. You gotta get the checklist done. We need these things percolating. We need these things marinating, all right? We need these things marinating. So make sure you've gone through the checklist. Make sure you've done all these things here. It's part of the homework that I asked you to submit, but I really need you to do it. These things take time to show up on a recruiter's radars.

And so we need you to get these things done. and I put it here, I'm giving you another shot to get it done. There's examples for everything. If you have questions about this stuff, I'll bring it to office hours. But yeah, you gotta get this done. There's a lot of little things here that really matter in the long run. And so please, please, please make sure you're going through it. There's something interesting that I read about LinkedIn. A lot of folks asked about the being open to work on LinkedIn. Apparently there's a setting that folks in your organization can't see that you're open to work for. So folks that wanted to put the open to work thing or open to opportunities on their LinkedIn, there is a setting that makes it so folks in your org can actually see it. So cool to know if that's something you're interested in doing. Recruiters only stuff like that. Yeah, so definitely check that out. There are some extra settings in there.

Yeah. And a lot of people are saying the open to opportunities is kind of like the best because you can say, oh yeah, I'm open to like, I do freelancing on the side or something like that, where you're not actually looking for a new jobs to be careful. And somebody saying, be careful if you're, if your company has a LinkedIn recruiter, be careful that might come up. Yep. Yeah. All righty, if you're pushing every day you should be pushing every day You're doing a code wars every day and you're pushing every day Because recruiters love those delicious green swears. So please make sure you're getting your code challenges every day Make sure you're pushing those challenges every day Be used to my squares looking nice. All right, that's what I love to hear, right? Those green squares start to look really nice, right? Make sure you're pushing every day. Not only is it about having a really good GitHub, but it's also about getting that practice in every single day, so that you become a lean, mean, code challenge, crushing, interview passing machine. Right? And so it's also about getting the green squares, But it's also about getting your brain into this habit of solving code challenges every day So by the time you're ready to interview and you have to solve a coding challenge easy Easy is what we do. It's what we do every single day. This is how we stand out This is how we slam dunk on the other candidates that are going out for the same positions They're not putting in the work that you're putting in Briar, we have a whole class on Git and GitHub that you can watch.

Yeah. Just go to YouTube, exclamation point, YouTube. Boom shakalaka. Exactly, Sal. All right. Push every day. Submitting your homework. If you have not submitted your freelancing information yet, please do so. For some folks, they have like a weird situation where they're doing like an hourly rate. So if you like withheld filling it out because you have an hourly rate Just estimate how many hours you're going to have worked and put that number in for me, please Yeah So, please if you held off because you're doing like you got like some folks had a contract but it's like an hourly rate just whatever that hourly rate was estimate the number of hours and fill that number in and Just put the number in there for me. It sucks out to go and clean it up So you haven't yet, please go ahead and fill in the freelancing submission I want to hear about if you got a paid client if you volunteered or if you contribute it to open-source software I think we're close to a one second Yeah, we're almost at a thousand people that filled out that form So if you haven't yet already go ahead and fill that out for me, please I really do appreciate it when I see what you're up to Even if it's no fill it out. So I know where you're at All right, if you haven't submitted the work from last week, the checklist, the 100 hours, the code wars, I left up the link for you so you can do it. All right, so you can do it. Preston said, I've been so busy. Hey, that's why I'm, guess what?

Hey, look, I got you. Look, look, look, I got you. Come on now, get in here. I'll give you extra days to get this stuff done. I got you, I got you. Come on, get in. No worries, I didn't take a look at it last week. I won't know just submit it. I'm gonna look at the timestamps. I got you get in All righty I got a new client should I resubmit? Yes, but just put the new client amount Don't don't like add both the amounts to submit the new the new amount Well All right, and then last but not least you have to be doing banky Banky is what helps our students get jobs. When folks from previous cohorts come back and they say, Leon, thank you, one of the things that they almost always bring up is that Banky came up during their interview process. The questions that were on the bank came up. The questions that were on the bank made them feel more confident in their answers. It's something you gotta commit to doing every day.

And you gotta... You gotta start now. You really can't put it off another week. You really can't put it off another two weeks. If you don't start now, it's gonna be too much, right as we're hitting our stride, right as we're trying to go into the interview process, you're still gonna not have it done. And so you've really gotta start this week. If you don't feel comfortable going through it by yourself, grab a group and do it on Discord together. Just post in general, post in your study community, whatever you need to do. So find a group of folks, work through it together if you can't do it by yourself. How many questions do you recommend doing a day? At least 10, at least 10 new ones a day. Yeah, so at least 10 new questions a day is where I think you should be at. Like we said, we say like this, it should be at least 10 hours outside of class time a week, right? So at least 10 hours of class time, at least 10 hours outside of class each week means that if you were doing two hours a day, Monday through Friday, that'd be like a half an hour of banky, half an hour of code wars, and an hour of getting through the reading or the projects, right? Some folks can do more.

Some have to do a little bit less. Everyone doesn't have the same privileges when it comes to time. Code Wars and Anki takes about an hour a day. Yeah, it's about right. Like some folks will take a little bit more. so it'll take a little bit less, but I think once you hit your rhythm and you've been doing it for a while, that hour mark is where it starts to get. Cool. Can you hit us with some of that motivation? I'm thinking about dropping out of 100 devs. All right. This might not be your moment. That's okay. It's okay. We'll always be here when the time is right. We'll be here for you.

But, but, you have a choice to make. You have a choice to make. And now you know the path ahead of you. You know the path ahead of you, right? You've come so far, you've learned so much. There's just a few more things you gotta do, right? There's only a few more things you gotta do. You gotta build a few projects, you gotta do some anchoring, you gotta do some code wars. You're in the home stretch. Whether you see it or not, you're in the home stretch. And so once you hit this home stretch, everyone has to make a decision. Is this something you want for yourself? Is this something you want for your family? Is this something that you want for your life? Do you want a high paid high growth career?

Do you want a career that has phenomenal benefits? Do you want a career that is ranked one of the happiest year after year after year? Because if you do Then you want to drop Because you've got a small army behind you that wants to see you be successful. You've got a small army here on Twitch chat, on Discord, that if you ask questions you will get help. When you are behind you can jump into voice channels, you can jump into Mindwolf's or Rufio's streams or Fox's streams to get help. You've got a small community behind you. But at the end of the day, we can't make you want it. That's a decision you have to make. But what I need you to realize is that you've come so far. Imagine, think back 30 classes ago when we were stressing about HTML and then you crushed it. Then we were stressing about CSS and you crushed it. Then we were stressing about functions and you crushed it. and across each of these classes, yes, it's hard. Yes, we might not be there fully understanding everything, but look at the stuff you've been able to build, the things you've been able to do, the things you've been able to accomplish, and know that you're on the precipice of being there. Like, you're almost done.

And so why throw in the towel right now? That doesn't really make sense to me. It happens a lot, and I'm gonna say this, because it happens a lot right as we get close to the end. And what I really think it is, is that a lot of folks don't feel they deserve the success. I don't know what it is, but that's what I that's like my if I had to guess is that for some folks, when they get close to winning. When we get close to getting the things that we dreamed about, the things that we want for ourselves, we rebel against that for some reason. When you can start to taste it just a little bit. Something clicks in our brain that imposter syndrome gets even worse and we start to self-sabotage. Happens every single cohort I've ever taught of students that are trying to learn how to code. It's happened every single time. Folks that I thought were doing phenomenally well in program, that I thought were producing great work, come to me and say, Hey, Leon, I don't think I, I don't think I'm getting it. I don't think I'm going to get a job and they, they, they leave at that point. And what they don't realize is that they just climbed a big ass hill. And if they had just gone another few feet, they would have been at the top. And what I'm telling you all right now, you have all climbed a big ass hill and you're so close to the top.

All right. You've been trudging through the trough of sorrow for so long in these next few weeks You're gonna be feeling those squiggles of fall soap Right. It was all the trough of sorrow. It's the thing I showed you from the very beginning We go through a long long long trough of sorrow. We get a little win Oh, maybe I understand what the back end is. I don't know how to do it yet But at least I understand it how many people in this world? never know the difference between front end and back end web development, right? You're there. And so over the next few weeks, you'll start to get your first squiggle of false hope, where you've learned enough to start building stuff. You've been prepping your interviews, right? And you're gonna start to get those squiggles. And that's honestly one of the hardest parts of the journey, because you get this little high and then you crash. You get this little high and you crash. You get this little high and you crash. and then after you crash a few times, you start to realize that you're on the upswing and then you get the job.

And so don't self-sabotage. You put in five months of work. Let's think about that. You put in five months of work and you're gonna sabotage it when you can see the finish line? It makes no sense. But we all have a choice to make. And what I hope you realize is that nobody else can ever make that choice for you. And at the end of the day, do you want a job that is high paid? That is high growth, meaning that for the rest of your career, your salary is going to keep going up, up and up where you have amazing benefits, where you're happy, where you can take care of yourself, your family, your future family. where you can feel proud about the work that you do, that you can build real things that real people use to have that satisfaction. Is that something you want? Because if it's something you want, you gotta make the decision to say, you know what? That's what I want and I'm gonna put in the work to get it. Because I can tell you that there are millions of other people that want the same thing that you want, but they don't wanna put in the work. Or they don't have the privilege of time coming together at this moment for them to put in the work.

And so if you have the privilege of the time to put in to make this work, don't waste it. It's not an opportunity that everyone gets. It's not an opportunity that should be taken lightly. It's something that if you stick it out for another few weeks, another few months, that'll change the rest of your life. And you want to throw in the channel makes no sense. It makes no sense. So you got to get the sillies out your brain. You got to get the self-doubt you got to get the imposter syndrome You got to push that shit way back in the back and get rid of it because you're close to something that is life-changing And when you're close to something that's life-changing right there was a I don't like the reference this moment but That that Denzel said this and I it stuck with me it's in my brain I can't get it out Denzel Washington said When you're at your highest, that's when the devil comes knocking, right? Y'all are close. Y'all are close. You're getting there. The devil's going to come and knock in. Things are going to start getting in your way. Life stuff's going to start getting in your way. Things that you didn't think we're getting, we're going to start getting in your way.

Imposter syndrome is going to start getting in your way. All these little things are going to start getting in your way. and that's why we have these wiggles of false hope. And so you put in all this work, you put in month after month of work, you're too close. You're too close to throw all that away, but I can't make you want it. If you want it, it's a time to put all that stuff behind. It's time to focus in on the things that have to get done. I'm telling you, the clear path of things that have to get done. You have to do your Anki. You have to do your Code Wars. You have to do your checklist. You have to do your Banky, right? You have to do these things every day. It's a binary, it's a yes or a no. Are you gonna do it and get the benefit of it or are you not gonna go back to the way that you were?

There's some boats and logs to be carried. Not everyone's gonna carry them, but the folks that do are not carrying them alone. Look at all these folks that are in Twitch chat right now. If you're here in Twitch chat and you will help somebody carry the boats and logs, just say, I'm here to help. Just put it so that the folks that are on the press, like that they're on that decision, yes or no, just say, I'm here to help. Let me pull this up. Look at chat. Now, if you typed in, I'm here to help, You got got, cause I got, I'm asking you to do something. I'm asking you today, tomorrow, this week, next week, I need you to go on those help channels. It's one thing for us to say, it's another thing for us to do it. And so there are some folks right now that the devil's coming to knock and there's some folks that are on that line where they gotta make the yes or no and they're gonna come ask for help. And if you typed I'm here to help, I expect you to be on Discord. This isn't self-taught, this is community-taught, which means we're all going to be in those help channels helping folks that are stuck. So you got a decision. You can carry some boats and logs for a few more weeks, for another few months, get something that will change your life, or you can go back to the way you were.

You can get off the roller coaster, but I'll tell you what, my inbox is full of students that have said, you know what, Leon, I wish I would have hung on and they're starting over again. Just see it through to the end. You'll surprise yourself and when it seems the darkest, when you feel like things aren't go on your way the most go on discord. And there are hundreds of folks that just committed to helping you right now. Literally hundreds of folks that just said, I'm here to help. And so don't you dare say there's not people that want to help you. Cause there's, there's hundreds of them here right now. You can start DM them right now on Twitch. Don't do that. Ask your questions on discord and the help channels. And we got folks that are here to help you. That's it. So you got this, you're gonna do this as a decision. I hope you make the right choice. Cool.

Alrighty, folks. Tonight, we have some really important topics to get through and these, more shark facts, These really important topics are really covered well by two individuals, Philip Roberts and Jake Archibald. Jake Archibald's video is kind of like the video that every person that writes Node professionally, like must watch. And Philip Roberts has a really good video that like breaks down the nitty gritty of the event loop and the stuff that we're going to cover tonight. It is actually your homework to watch these two videos. That's how foundational, right? Right? That's how foundational they are to being an engineer that uses Node professionally. Right? They're definitely meaty. There's a lot to them, right? But these folks have really broken down what I believe are some of the most important concepts in a way that really makes sense. And so some of the stuff I do later today is heavily influenced from their videos So you're gonna see some stuff that looks familiar and then when you watch these videos, they're gonna go deeper So it's part of your homework. You have to watch these two videos But I also want to make it very very clear that a lot of stuff that we're covering tonight. I have Incorporated from the watching those videos myself and it's really helped It's really helped me build out the slides and the things that we're gonna talk about tonight So all props to Philip and Jake.

It's really important that you watch these videos. Cool. Jake's talk is a banger. I agree. It's probably one of my favorite, favorite videos. Are we gonna learn RESTful APIs? Exactly. Yeah, yes we are. Ooh, I got you. Cool. All right. Let's back that backend up. But before we do that, Before we back in this back end up, we got to talk a little bit more about the JavaScript we learned last week. So I want to bring it back. I want to talk through the beginnings of what we talked about last class so that we can lean into the deeper, meatier topics.

I had some slides that said, the by Felicia slides. I had those, but we're going to bring those back. And so to get into those more meaty topics, we want to cover the basics. Cool. So JavaScript is single threaded, meaning it is synchronous. It does one thing at a time. It is not a multi-threaded language. There are some multi-threaded languages. And the way I like to think about a single-threaded versus a multi-threaded language is let's say we owned a paper company and we wanted to deliver those papers. we could have a singular paper delivery person, or we could have multiple paper delivery persons. The wonderful thing with multiple delivery persons is that you can deliver multiple papers at one time, but you might run into some more problems. Single-threaded, it might take a little bit longer to deliver all those papers, but you could run into less complications. And what we're gonna see over the next few classes is that single-threaded actually winds up being one of our most beneficial things that makes Node fast, that makes it a wonderful language to use. And so we're gonna lean into this idea of being single-threaded and the advantages that it can bring. Cool.

If JavaScript is single-threaded, if it is synchronous, meaning we do one thing after another, how do we do stuff like make an API request and keep scrolling on the page? How do we like something and keep moving through other posts? Like how are we doing all this stuff? That's gonna take some time For it to resolve and how are we not just stuck there waiting for it? Because of the environment exactly in JavaScript things should block like all those tasks could have to wait until the first one finishes and and then move on to the next one. What up, bro, right? So we normally would have to wait, right? We'd have to normally sit there and be blocked. But since we are running JavaScript in the environment, we get access to the ability to hand off all of those tasks, all those asynchronous tasks, we have the ability to hand them off based on the environment in which we are running JavaScript. So when I talk about the environment, I'm not talking about this. I'm talking about this. Look at that. Whoo And it's glory It's glory. That's what I'm talking about. We're running our JavaScript in the browser, right when I'm talking about the environment right now I'm talking about running my JavaScript in the browser Eventually, we'll run our JavaScript in another environment but the first environment, the environment that we've been running our code in all this time was the browser.

Okay. Since our JavaScript is running in the browser, we get access to a bunch of what, chat? Since our JavaScript is running in the browser, we get access to a bunch of what? Yeah. We get access to a bunch of web APIs. Remember the browsers come bundled with all of this technology and our JavaScript gets access to it since it's running in the browser. So just simply by running our JavaScript in the browser, we get access to all these other goodies that JavaScript itself would never have like built into the actual language, so a lot of this stuff that's asynchronous that would normally be blocking behavior in JavaScript. JavaScript's not actually handling, it's handing off all these blocking things to the web APIs that can go ahead and do them on our behalf. And tonight, what we're going to learn is how that is actually happening underneath the hood. Like what's happening? Like, how are we doing this handoff? How is JavaScript, which is a synchronous blocking language? How are we able to do all these async stuff? That's we're going to get to tonight. This realization makes the appreciate browsers more.

It really does. These Browsers do a lot of work a lot of heavy lifting and do it and enable us to do a lot of things We wouldn't been able to do before Durva said I read an article today talking about Apple stubborn refusal to improve Safari's web APIs on iOS devices to force apps on the App Store to run more smoothly so they can keep getting their 35% cut So I haven't read that, but let's talk about, let's say if that was true, right? If that was true, let's talk about that because that's a really interesting thing. When you're running a browser on an iOS device, you are using, you are using Safari. Even if you're using Chrome, even if you're using Firefox, Firefox, they are all skinned Safari, right? Like it's not the same, right? It's pretty interesting. It's just Safari underneath the hood. And so Safari is exposing certain web APIs. And since Apple has control over what web APIs it provides, right, what web APIs it provides in its browser, we could see that maybe the browser isn't keeping pace with the web standard. Now, I'm not saying that's what's happening. I think this is an interesting thought experiment. Since we are in a walled garden, right? Right? And since the browsers get to choose what APIs are exposed, there could be a scenario where Apple says, you know what, let's not expose these APIs in the browser so that folks have to continue to build mobile apps that get access to those features, right?

We could live in a world where Safari gave us access to everything, like the gyroscope, the camera system, like all these things that the phone has access to, you could make Safari have access to all of that stuff, Right, like there's a way to build into the web APIs access to all that stuff, right? And so maybe there is a scenario where that's not happening so that you have to build mobile apps that get access to that stuff. Now, like I said, I have no idea if this is true or not. I have no idea if like that's what's actually happening. I just think it's an interesting thought experiment because now we understand that JavaScript is running in the browser and JavaScript only has access to what the browser provides via the web APIs. Right? I don't think this is a reason to dislike Apple. I think it's just an interesting thing to think through. Right? It's a very interesting thing to think through. right, this idea, right, there's this idea that the browsers, and let's not lay it all just on Apple's foot, the browsers like Chrome, like Safari, like Firefox, they all have a responsibility to keep up with a web standard. And if we go back in the day, they didn't. They didn't all play well together. We had Netscape Navigator, then we had IE, IE and then IE and Netscape Navigator weren't playing nice to each other and so Firefox came on the scene and was like hey Whoa, I'm gonna fix all these things right and then we had the browser wars and it wasn't until like 10 years later right It wasn't until like 10 years later that they all decided to start playing nice to each other and it wasn't really until like 2015 when we really got all of the goodies starting to come through on a regular basis So the web is still a new thing, right? And we're starting to understand maybe why, because well, each browser is different.

Each browser really could expose their own APIs that are different from the other browsers. And so what could have wound up happening is that we could write JavaScript, but when you started to run it in the different browsers, it might not have access to all the same things. And so we talked about something that we used to use in the past that helped us write JavaScript once and have it work on all the different browsers. What was that thing that we used to use back in the day? Shout out, sorry to hear that. We're here when you come back. Take care. Yeah, we used to use jQuery. jQuery enabled us to write JavaScript and then jQuery did all the heavy lifting to make it work in all the different browsers that might've been exposing all different APIs, right? But now all the browsers are playing nice with each other. Right? Right? Now all the browsers are playing nice to each other. So we don't really need jQuery anymore because that cross browser compatibility that it brought to the table is just really not something that we need at the moment. Cool.

So my first website I ever built was a Netscape Navigator. Yeah, Netscape Navigator had a like tool to build websites. And I remember like in the library using Netscape to build my first website. You know, I've been around the block. Geocities is where I hosted my Dragon Ball Z RP group. We used to play on aim. There used to be aim chat rooms with a roll dice command and we used to play Dragon Ball Z like role-playing games based on the roll of dice and like that's how you would know like if you want to fight or not. Get around the block, folks. All right. Now, we're starting to learn all this stuff. We keep talking about this thing called browser APIs. And when you look at the list of browser APIs, you see that one of the things that's on this list of APIs that come with the browser is something called the DOM. And I just remember the first time I learned this, my mind just exploded. That JavaScript does not actually come with the DOM or access to the DOM. Access to the DOM is provided via a web API that comes with the browser.

So whenever you did document.querySelector, that wasn't JavaScript, all right? That wasn't JavaScript. That was a web API that JavaScript had access to because our JavaScript was running where? in the browser. The reason we had access to the DOM and query selector, query selector, all of those things, was not because it came with JavaScript, but because we were running our JavaScript in the browser, which exposes all these APIs that we can use, but it's not actually part of JavaScript. Now, interestingly enough, is what we call this like document.querySelector. Now, if the DOM is an API, what is the document.querySelector here? There's a word that I might call this. I'm gonna use, I can use it very loosely here. A very, very loose word here, but I could use it. It is a method, that is correct, but we access, what is an API? What is an API? Let's step back. Let's think about what an API is. Yeah, it's a simple interface to do something complex.

So manipulating the DOM is the very complex thing that we are doing. That makes the document.querySelector technically our what? Our interface, right? It's the interface. It's the simple thing that we can use that does a lot of complex stuff. Think, we just do document.querySelector, and it knows how to go into the DOM, grab stuff from the DOM. It's doing all these complex actions because we use that interface. Same thing like a remote on a remote control. Right? Think about like a remote and a remote control. You press a button, that button is the interface that does something complex in your TV. Lang said, this is so great. Paid for a bootcamp, didn't learn any of this. I'm telling you folks, folks coming out of bootcamps, like you don't have to listen to me. I tell this stuff to you all the time.

Listen to folks in chat. I'm telling you, you're running circles around folks coming out of these other bootcamps. They don't learn this stuff. I know people that are writing JavaScript professionally that don't know this stuff, but it does help you as we go deeper and deeper and know to really understand what's happening underneath the hood. All right, so all that stuff that we were worried about, We know that JavaScript is a synchronous language. It does one thing after another. It should block all the stuff that we would consider blocking. We can do because JavaScript is handing off all that asynchronous stuff, all that stuff that would take time and would normally block in a single threaded language, we're handing all that stuff off to web APIs and web APIs can do that. Asynchronously. With JavaScript hands that off to the browser, the browser does its thing, right? The browser does its thing. And then once it's done, it responds back to JavaScript so we can use it and keep on moving. So tonight we're actually gonna see how that happens, how we hand that stuff off to the browser, right? And come back. Cool.

Because if we're handing off all this stuff to the browser, we need to handle how it comes back. And we first originally handled all these things coming back with what? We would hand off stuff to web APIs. And then when those were done, we could do the next thing by using what? Or the ways that we handled the responses back from the web APIs. Yeah, we used to use callbacks, but callbacks led to what? Callbacks led to what? Hell exactly they they they led to they led to call back hell, which we'll see again tonight and so with ECMAScript 2015 we had a promise for a new future right where we brought in promises and Promises were just an object that could have a value in the future and they came with some methods like the then methods or the the catch methods. So once the promise did have a value or it resolved, the thens methods would fire. And if there were any errors, the catch method would fire. And then we were like, all right, these promises are great, but they don't read too well. They kind of, there's like this chaining syntax that's going on. And so with ECMAScript 2018, we added some syntactical sugar on the top and that was async await. So we're gonna see those again tonight. We're gonna see that progression tonight, but I I used a big word called ECMAScript What is ECMAScript?

Yeah so JavaScript is an Implementation. I'm using these words loosely here for educational sake, right? JavaScript is an implementation of a standard or a specification. And so when we keep talking about JavaScript updating, it's really not JavaScript that's updating necessarily. I can feel the nerds shaking. It's ECMAScript that is updating. and ECMAScript has a council that approves what changes occur. And so in 2015, we had a lot of really big changes and these big changes brought things like const and let all these wonderful things that we've been using throughout the entire program together, right? And all those big foundational changes, we called ES6 or ECMAScript 2016. So everything from 2015 2016 that the standards body agreed on right that then right that then I'm gonna Time out although before anybody answers that That All those things that we got all those goodies that we got Right all those goodies that we got that were part of the standard or the specification that was ECMAScript, of which JavaScript is just an implementation of. And so in 2016, we got all these goodies and we called that ES6, right? So that was all the big changes that happened in 2015 that happened in 2016, right? And then the standard kept improving. And so we got async await when? And does anybody know when we got async await?

ECMAScript what? Yeah, ES8 or ECMAScript 2018 is when we got the async await specification. And so that got bundled into JavaScript as we know it now. So JavaScript, which is an implementation of the standard ECMAScript, keeps getting updated to give us all these wonderful things. And so when we come back from break, we're going to see what we used to have to struggle with, which were callbacks. We're going to see that progression into promises and the newer async await syntax. And then once we feel good about those things again, we're going to get got. And when we get got, we're going to understand how to not get got and go get by understanding the event loop and how JavaScript is actually passing off all this asynchronous this stuff to the browser so we can do the things that we want to do. But for now, we're going to take a break around here. We'll take a break at the top of every hour. If you're able, please get up, move around, hydrate, look at something that's not the screen. Let your eyes relax. And remember, we're going a little fast through this stuff. If you, if you missed last class, we're kind of just reviewing everything that we spent the whole class on last time. So make sure you go back to YouTube exclamation point, YouTube.

You can watch that full class get that all in and if you have questions Hundreds of folks said that they're willing to help you and they're gonna be on discord to help you So after class jump on discord ask your questions come to office hours with them five minutes on the clock See y'all very soon. Yo, if you have glasses clean them just saying I Clean my I just clean my glasses a different world All right Got the dishes done, woo, all right, seven minutes, y'all here. Alrighty, so we want to jump through callbacks, promises, async await, so we can get to underneath the hood what's actually happening. And someone brought up a really good question right as we took a break. And the question was like, why do we need to know, why do we need to know that JavaScript doesn't do this and that it's the web APIs that are doing it. And my answer is so we can destroy the competition so that we can be beasts when it comes to the technical interview. So we can go further than anyone has gone before so that we can destroy those which need to be destroyed. That's why. We don't get got, we go get. we want to be better than everyone else. We really do. That's it. That's the reason. So many folks coming out of bootcamp, so many folks coming out of CS programs have no idea that this stuff is even existing or understands what it is. And so when we understand it, not only does it help us when it comes to interviewing, not only does it come time to help us, but it gives us this understanding that makes you think differently about your code going into the future.

Once you understand that this stuff doesn't come with JavaScript, that it's the web API that gives it access to it, then when you start writing Node, you're gonna be like, wait a minute, Node doesn't have web APIs, what does it have, right? And what is JavaScript accessing when we run it in Node? Are there other places that we could run our Node? And once we understand how the event loop runs, then maybe we could write more performant JavaScript. And so there's a lot of stuff that if you have this, like this fundamental understanding, right? If you have this fundamental understanding, it helps you think differently for the rest of your development career when you're using Node. And it also introduces some really important concepts, right? It introduces things like stacks and queues, which are fundamental data structures that we're gonna use, especially when we get to interviewing. And so I don't like to introduce stacks and queues and some like, here's the algorithm data structures you need to pass the interview way. I want to show you how stacks and queues they're used in real life every single day, so that you have a real understanding of this stuff. Some folks will spend a whole semester learning data structures and algorithms, but have no idea like how to apply them or where they actually come up, right? And to me, I think that's kind of a shame. And so I really like this topic because it helps you really critically think about what's happening in the browser, what's happening in node. And then also like you start to see some of the really fundamental data structures. And then even some algorithms we'll see next week that we're going to use throughout the rest of your time as a software engineer.

Yeah. No worries, Daisy. So yeah. Other than like destroying our enemies, this is, that's why. I just think it's fun. I think it's cool to like know that how this stuff works. All right. Next, let's keep pushing here. All right, so we talked about this idea that all this stuff is being handed off to the web APIs and eventually they have to respond. And so the way we did this before was with callbacks, but to understand callbacks, you have to understand something fundamental before callbacks, right? So we have to understand that in JavaScript, a function can take another function as an argument. When you have a function that takes another function as an argument, what is that parent function called? Yeah, it's a higher order function, exactly. And you have seen this a bazillion times. Every single time you've used an event listener and you've created a click event, you have created a higher order function.

So here we have addEventListener. It's a function. We see that takes in click, and it also takes in a function as an argument. What the heck do we call the function that's passed in as an argument? If you have a higher order function, a function that takes in a function, what do you call the function that's being taken in? Yeah, we call that function a callback. And so we've seen this a bazillion times at event listener would be the higher order function, and whatever function runs based on the click would be your callback. Now, callback is the thing that callback is the function that's passed in as an argument, but it's not really a thing in JavaScript. There's no like thing in the specification called a callback. It's really just a convention. And it's something that we use to like really help us when it comes to writing JavaScript. Because a callback can fire once an asynchronous task is done, right? Once an asynchronous task is done, we can use the callback to be fired after. And before we got to promises, and before we got to async await, we needed callbacks so there'd be no way for us to handle all this asynchronous stuff that was happening in the browser. Without callbacks, JavaScript would chew, chew, chew along.

It wouldn't wait for anything, and we wouldn't be able to build the applications that we know and love. So callbacks were the original way that something asynchronous could happen, and then the next thing would happen after it. So here is a mess of callbacks. We have a setTimeout, and then once the setTimeout is done, it'll console.log, and then we have another set timeout, and when that is done, it'll console log, and we have another set timeout, and when that is done, it'll console log. And so this nested list of callbacks, we refer to as the pyramid of doom or callback hell, right? And so to avoid callback hell, we were given a promise of a better future, right? What if there was a way to more, a more readable way to handle asynchronous code, instead of nesting our crap inside of other crap? What if there was a way that we could have a more readable way to handle asynchronous code? And that's where promises came into the game. Now, people lose their minds when they hear about a promise, right? All a promise is, is an object. And it's an object that can have a value at some time in the future. You gotta think about the promises having three states, pending, fulfilled, and rejected. And if the promise is fulfilled and it's done resolving, it has some methods that can fire. So once the promise has a value and it's resolved, the then methods all start firing.

They kind of just fire one after another. And if something was to go wrong, what method would fire instead of the thens? It's an IOU. Yeah, you can think of it as an IOU. I like that idea. A catch would fire. So promise is an object that can have a value. Once that value resolves all the then start firing is something was to Happen or go wrong then the catch would fire instead cool We've seen this before We've seen this before it's not something that's new. It's not something that should shake us to our core We've seen it with fetch all the time Fetch is a what? Fetch is a what? It's a web API. It's a web API. Now, when I say web API, what the heck do I mean? I keep saying web API, web API, web API, web API. I keep saying web API, web API, web API, web API, web API.

What the heck do I mean by web API? Hey, does this work? I web API, web API, web API, web API. What do I mean? Yeah, so then the browser's giving us, right? we have a simple interface that enables us to do something really complex and the browser's handling it for us. So Fetch is our really simple interface to do something really complex that the browser's handling, like going and getting that information, right? Going and getting that information is something the browser is handling for us. And most of our web APIs respond with a what? Most of our web APIs respond with a what? A promise. Yeah, they respond with a promise, right? And that promise may have a value. And once that promise resolves, right? Once that promise resolves and it has that value, what fires?

What fires? The dens, exactly. And so that's why these dens run after we hear back from the API. Like once we hear back from the Doc CEO API, these dens fire because it's not something about the API. What it is is that the fetch is a web API that is giving us a promise. When that promise resolves, boom, then fires, then boom, the next then fires. And if something was to go wrong, then we would skip the thens and go straight to the catch. What's something that could go wrong with our fetch? What's something that could go wrong with our fetch? Yeah, we get a 404, like maybe the API is down. Maybe it doesn't exist. Maybe we typed in the wrong URL. There's so many things that could go wrong when you're making a request to another server. And so if any of those things went wrong, well, then our catch could fire. And our catch would handle that error, and we would console log and see the error.

Oh, not authenticated. Yeah, a bunch of stuff that could happen. All right. So fetch returns a promise, just like a bunch of other web APIs that are running asynchronous code. This is really key for us to remember later on. Fetch is a web API. Web APIs probably return a promise. Why do you think web APIs return promises? We're not there yet, but I think it's an interesting question to just think about for a quick second, and then we're going to see it later on. Yeah, it takes time, right? All these web APIs, all this asynchronous stuff takes time, But JavaScript can't wait her long for that. JavaScript wants a promise of some data in the future Right, and so they let me pass just give it a promise and that promise eventually has some value So JavaScript can keep on trucking JavaScript is a synchronous single-threaded language. It waits for no one. It just keeps moving It's an impatient exactly All right We looked at some wild code here And this code looks a little heavy at first, but what we're seeing here is that each one of these functions returns a what? Each one of my functions here is returning a what?

Yeah, each one of my functions here is returning a promise. And so when I call house1, this promise will resolve. And once it resolves, what's gonna happen? We have the set time. It's going to take a second, but once it's done, it's going to resolve. And what's going to what's going to happen as soon as the house one, we called it as a function call, but it's returned to promise that promise resolves what happens? Right, all the dens start firing one after another, the promise chain starts going off, Right? Hey, does this work? Web API. Web API. Does this work? All right. So we have this. We have this web API, right. Or sorry, in this case the promise that resolves as soon as the promise resolves the then start firing, right?

And so we can see inside one of the thens, house two would run, which also returns a promise, which would also resolve, and then the then, the then, the then, the then, the then, the then, the then, right? That's it. We see all these thens dischained and running one after another. And so this works, right? This is a this is a decent way of handling promises. We use this for a while, but it don't read too good. How does reject fit into this? Well, if it's rejected, the catch would fire. So if at any point in time, our promise, our promise was rejected and didn't resolve to be fulfilled, then the catch would fire. But the then's all fired because all of our promises resolved because we literally told them to resolve, right? Like we told them all to resolve. There's really not a way that this would not resolve. So all of our then's keep firing and that's fine. It's just that it don't read too good. Like it doesn't look like JavaScript that we would normally write.

Like we just have all these chains. It's kind of messy. It's not really easy to read. It is gonna get increasingly harder and harder to see what's happening inside of this, Like these promise chains and we're kind of back out. We're not back at callback hell But we're in a thing that's just not like doesn't feel good doesn't feel like regular javascript. And so A lot of folks said hey I want my asynchronous code to look synchronous and I want it now Right. They started to complain a little bit like hey, you gave us a promise of a better future Right, but it don't read too good Right. I want it to look synchronous. JavaScript is a synchronous language and I want it to look like the rest of my code. And so we got async await. With ES8 or ECMAScript 2018, we got async await. 877 code now. Hold on, I'll give it, I'm giving them VIP. How, can I just VIP you like this? I was gonna copy your name.

You on, heck, there you go, you got VIP. Maybe laugh way too loud. If you make me laugh out off the charts you get VIP There you go We give VIP for being funny exactly juice box get in here give me a commute that give me the one-liners I need them easy easy VIP That was hilarious The what if you don't know what that why I'm laughing it's a rip on a commercial a JG Wentworth commercial So it's my money and I want it now. Oh boy, alright, so they want it. They wanted their asynchronous code. They wanted it now they they they wanted a syntax that looked a little bit more synchronous and so we had a new way of handle these async responses. But underneath the hood. Boomer jokes. I don't know if I told you, but, uh, boomer jokes, exactly. Um, this async await that we got with ES8 was just promises underneath the hood. It was just a little, a little syntactical sugar that we are putting on top of our promises. Uh, it's almost like JavaScript written in like 10 days and we have to keep making it better. we have to like keep like putting sugar on it to make it palatable right I don't know just he's a little weird right and so we put this little syntactical sugar it's just promises underneath the hood but oh baby oh baby we have this wonderful await syntax and await waits for any async process to be complete as long as it is inside of an async function and here we go we have our normal functions that have the promises but then inside of it look at this sweet mama jama look at this oh oh we're inside of an async function and we're just a weight in each thing, well look at that. Damn. It looks like the synchronous code that we know and love when writing JavaScript, but it's handling all these async tasks because we're inside of an async function, we're awaiting, and so this asynchronous thing can go off, it can do its thing, The promise will resolve and then whatever that value from the promise resolving is now stored in house one Wait, and then we await whatever came back from a house to that that promise resolves Whatever value the promise had is now in house to wait Same thing with house three and we can just console log them like normal and it look Ooh.

Passion said, wow, this is hot. It is. This is some hot code right here. I wish all my code could be looked like this. It's pretty, right? From, from, from, but you got to think about it, like the buildup, right? We got to think about the buildup. From, from this hot mess, imagine if this was real code, right? Like where you actually had to like, your job is to like get in the code and figure out what's going on and you see this, you know, like the Simpsons meme where like home, like Homer's dad, like walks in, puts the hat on, sees that Bart's at the desk and turns around and walks back out, that would be me in this code base, right? You would walk in, see it. Nope. I'm out. I quit. Take your money back. Here you go.

Right? And forget the dental plan. Right? So we went from this, which would just be a hot, hot garbage and mess, literally call back hell. We built up to a promise for a better future, right, like this promise chain. Like that, that's okay, right? Like it reads okay, but still kind of messy. Like we got to like see what's going on inside of these. To this, to this hot piece of code. You know, I didn't feel like a boomer until I started saying, well, back in my day, We wrote callbacks, right? Back in my day, we wrote callback. That's when I, that's when I knew I was getting old back in my day. We didn't have any of this fancy dancy, async await stuff. You know what we had to do back in my day, then, then, then, then, then, then, then, then, and then we would ask herself, Hey, does this work? And then we, then, then, then, then, then, then, then, then, then, right?

Like, like you Gen Zers these days. is get all this good, clean, async await code. You don't know the pain. I've saved you from the pain. The ECMAScript council has saved you from the pain. You'll never know. All right. Now this is all fine and dandy. Thank you, C-Sharp, exactly. I need something real. Like when would I actually use this, right? Sorry, sorry, this is a Wendy's. When would we actually use this, right? Well, here's an API request, and it just looks so good, right? It's so good.

Does syntactic sugar make our code more slow? No, because it's still promises underneath the hood. Just a little bit different syntax, but it's still using promises underneath the hood, right? All right, so here we're inside of an async function. And so we can await the fetch. The fetch will return a promise. And then the result of that promise, the value that that promise has will be stored in res. And then we can await that lovely JSONification of whatever came back. And then we can actually just console log whatever came back from that await, right? So we have this what was normally a a fetch with promise chains We've turned into a beautiful async function now. I asked you for homework This async is is missing something It's missing how we handle errors. So we need a try and a catch block. It works without the try and catch But right now we're not catching any errors. So part of your homework before Sunday I need you to come back to this code and try out try and catch blocks and you're like Leon I have no idea how to use try and catches. Where could you go to see the syntax of a try and catch blocks?

MDN exactly MDN let's go. Cool. So Before we get into the event loop, I want to use a web API like setTimeout. Let's use a web API like setTimeout. SetTimeout and SetInterval are not part of the JavaScript or the ECMAScript specification. If we go and look at the ECMAScript specification, we will not see SetTimeout, We will not see setInterval, therefore they are not actually part of JavaScript. However, most environments give us access to them, like all the browsers, Node.js, they all give you access to setTimeout, setInterval. And it makes a lot of sense. Why can't JavaScript have setTimeout built in? Yeah, it's single-threaded, it's synchronous. It literally can't wait. It can't wait for the setTimeout to finish. It has to choo-choo, keep moving, right? It can't, it's single-threaded. It literally can't exist.

Now, here's an interesting thing. Let's see if we're pro gamers or not. SetTimeout in the browser is a web API, right? SetTimeout, you're with me? Hold on. Come with me. Get in. We're getting close. SetTimeout in the browser is a web API. When we get to node, is setTimeout still a web API? Can't be because we're not in the fricking browser anymore. So literally the setTimeouts we're using are different in the browser and they're different in node Because JavaScript doesn't have set timeout. It's something that's being given to us by the environment that we're running JavaScript in. What the fuck's going on? They're not the same.

They're built different. They're literally built different. Now I'm using setTimeout as an example here, but there are a lot of other things that aren't necessarily setTimeout, where one's gonna be a web API, and the others are gonna be C and C++ APIs. So where we have the browser to handle this stuff, Node has its environment that gives us access to C and C++ stuff. So while one might be a web API, the other might actually be APIs that are coming from C and C++, right? And now there's some crossover, right? We are still using the V8 engine. We're still using a lot of the same stuff underneath the hood but we don't have access to the browser which is literally a program running on our computer. So we don't get access to some stuff. And we run it in Node, we don't get access to some stuff. They're different environments, right? They're different environments. All right, here's some code that I definitely, I want to run this code. So let me go ahead and I'm just going to, I'm going to open this in the starter code. If you don't have the starter code, it's the same starter code as last class.

But if you need the code to follow along, you can join our Discord, exclamation point, Discord. Agree to the rules. And when you join, you'll see a follow-up material that has all the materials. How many people do we have on Discord right now? Oh, 32,900 people. We're almost at 33,000 people on Discord, that's wild. 32,900, woo, let's go. All right, I actually wanna type this one out. I will not type it out, I just wanna run it. And so, this is one that has the set timeout, so let's go ahead and take a look at that. All right, here we go. I'm going to uncomment this. I am going to open it in the browser. One second. All right, going to open up my inspector.

I'm going to go to my console and let's take a look at this. So here we have function one, which is a normal console log. This is the async practice folder. You're not coding anything. It's just if you wanted to run the code in your own browser You could but you can probably you get the same thing just following along cool now we have Function house 2 which has a set timeout of 3 seconds And then we have a function of house 3 that has a console log right Cool. All right. So, if we look at this, we would expect JavaScript's gonna run, house one, then house two, then house three. We know JavaScript is single-threaded, it doesn't wait. So, we would expect house one to run, and we would see the paper delivered to house one in the console. Then we know that this one would take three seconds, So that's gonna have to go do its own thing. JavaScript's not gonna wait. We're gonna have three, house three, and then eventually this is done, and we would see house two. And when we run it, that's exactly what we see. We see paper delivered to house one, then house three, and then house two. And it's like, all right, well, that makes sense because there was a three second delay, right?

There was a three second delay. So it makes sense that it went one, three, two. But when we get rid of this delay and we save this and we run it, there's no delay. The first time we had the three second delay. So that made sense. We did one, three, then two, because this two is taking three seconds, right? Why is 3000 three seconds? Cause it's milliseconds. So 3000 is three seconds. And so let's just go ahead and make this zero seconds. So no delay by today, right? No delay by today. We would expect one, two, three to happen. There's no delay by today, no delay, right? But when we save this and we run it in the browser, we still get the same thing.

One, three, two. Now why is it still one, three, two? It's zero. There's no delay by today. Why does it just run it and have it one, two, three? We changed it to zero. There should be no delay. We should be able to buy it today. Well, we got got. Y'all came to get, and we got got by the event loop. Right, we got got. Tag your jabroni friends on Discord. You got got. Right, we got got because setTimeout is a web API. Right, setTimeout is a web API, which means it has to be handed off to the browser.

Right, has to be handed off to the browser, which takes time. Even though there was no delay, It still had to be handed off to the browser. So we couldn't buy today and we got got By the event loop So We need to learn a few data structures So that we can write this wrong and not get got in the future. All right, we need to learn some data structures Once we learn two data structures, we're going to be able to see the event loop underneath the hood and not get got. So let's learn some data structures. There are two really found like fundamental data structures that are very easy to implement in JavaScript that show up throughout your programming career. and they form the two really important pieces, right? They form two really important pieces that show up over and over again when you're trying to understand how JavaScript is running in the browser and then how it's eventually running in Node. So the first data structure is a queue. And you could think of a queue just like a fancy word for a line, right? You get into the queue, if you're from the UK, you queue, you don't stand in line, right? And so you get into a queue and if you're the first person into the queue, you are the first out, right? You're trying to buy movie tickets. You get into the line and if you're first in line, you're the first to get the tickets. So a queue we call a first in first out data structure, the first person into the line or the first person into the queue is the first out.

I also like to think of it as frisbees. So let's say you are all, we're all playing frisbee together. We have lots of frisbees going and somebody just type frisbee in chat so I can see some people here. All right. Beautiful. All right, so this is Minty threw a frisbee, Reese threw a frisbee and Garrett threw a frisbee. So Minty threw a frisbee and I put it on my plate, right? Reesey threw a frisbee, I put it on my plate and then Garrett threw the frisbee and it went on my plate. So I have all these frisbees that are now, I'm holding all these frisbees, right? Holding all these frisbees. And when I go to throw the frisbees, I'm gonna throw from the bottom, right? I'm gonna throw from the bottom, right? So the first frisbee into the queue is the first frisbee out because that's the one I'm gonna grab and throw Alright, so I like to think of frisbees frisbees are coming in. I'm grabbing the bottom frisbee and throwing them back out You could also think of it as like a line The first person into the line is the first person out and that is a queue now in JavaScript it is pretty easy Right So the opposite of a stack in Magic the Gathering? Yeah, sort of.

If you've played Magic, you know what a stack is. We're gonna get to that in a second. Cool. So now we can implement a queue pretty easily in JavaScript if we use an array. And so here we have push. And so I have my queue that I've declared using literal notation to create the array. And I went ahead and I pushed the number two into the queue. Then I went ahead and I pushed the number five into my queue. And so if we were to look at the queue now, we would see two and five. And then I shift, which means I'm pulling the first value off of the queue, and I'm alerting that value. So this queue here is an example of a first in, First out data structure or a queue where the things were pushed into the array The numbers were pushed into the array and then we shifted off those numbers. So the first in was the first out Cool First try All righty, oh boy, dogs in the house, I see y'all. All right, now, the next data structure, the MTG players want to channel, hey, if y'all started using the game together, maybe. Maybe game blouses, exactly. All right, now, here we have a stack.

When I think of a stack, I think of pancakes, right? When you're making pancakes, you put a pancake onto a stack. And what happens, unless you're a monster, is you keep putting pancakes on the stack, and then as you go to serve the pancakes to your friends and family, right? The last pancake on the stack is the first one out. So you're making pancakes, you keep flopping pancakes higher and higher on the stack. And the last pancake you put on the stack is the first pancake off, right? So whereas a queue is first in first out, A stack is last in first out. So you have a stack of pancakes. You're putting more and more and more on the stack. You're not going to pull the pancake at the bottom to get it out. No, your whole stack of delicious pancakes would go everywhere. Your family would hate you, right? So unless you're a monster, pancakes are stacks, right? You keep putting pancakes higher and higher on the stack. And the last pancake in the stack is the first pancake off.

And so we just take our pancakes off off off all the way down to the bottom of the stack. So Q is what kind of structure Q is what kind of structure? Give me the the name for it FIFO exactly first in first out you're the first in the line you're the first out of the line a Stack is what kind of data structure? Give me the give me the name for it Leafo exactly last in First out meaning the last pancake on the stack is the first pancake off the stack beautiful Now here's a stack example using javascript once again and we're gonna use an array. And so we push our two into the array, we push our five into the array, and now we have two and five in the array. And instead of shifting, which would be a queue, we pop, which means the last thing that was on the array is the first thing out. So since the five was the last thing into the array, it is the first thing out. And so we'd wind up alerting five and the stack would be left with just two. Cool. So we have our lovely. Q, which is a first in first out, and we have our stack, which is a last in first out and we're gonna need both of these right we're gonna need both of these these queues and stacks to stop us from getting got all right we need the power of queues and we need the power of stacks to not get got so we're gonna to take our break. We're going to put five minutes on the clock. We had a couple of hydrates come in here. Thank you for the hydration. So let's see here.

Wisconsin. Hey, thank you for the hydration. Cheers to you. Linda Shrews. Hey, cheers to you. Thank you for the hydration. We're going to take a break. And when we come back, we're going to put our cues and our stacks into practice to stop us from getting got. All right, folks, five minutes on the clock. If you're able, please get up, move around, hydrate. You got, got. So let's talk about not getting got. Let's talk about not getting got. So we talked about this idea of a, talked about this idea of a first in first out, which is a queue. And we talked about this last in, last out, right?

This last in, last out, sorry, last in, first out. So this first in, first out and last out, last in, first out. So a FIFO and a LIFO, a queue and a stack, right? A queue and a stack, right? a queue and a stack. And we wanna implement these queues and stacks in ways that help us not get gotten. And so what we have to realize is that JavaScript is running in the browser. And since JavaScript, right? Since JavaScript is running in the browser, we get access to a few things. First, we get access to something called the V8 engine. Remember, our JavaScript is not something that the computer understands, right? Our JavaScript is not something that the computer understands and so it has to be broken down from the JavaScript that's human readable to us into something that the computer can actually understand. So the V8 engine comes with a couple bits and pieces. Folks that come from like a more computer science-y background might initially think of the V8 engine as a what? Could've had a V8, exactly.

Yeah, similar to like a compiler, right? Something that's gonna take your code and break it down to something that the computer can understand. Compiler, interpreter, root, We'll eventually figure out all these distinctions, but the V8 engine is a little bit more than just that compiler. It also has things like memory management and garbage collecting, stuff that a language like JavaScript really doesn't have natively. And so we get all that stuff by running our JavaScript in the browser, which gives it access to the V8 engine. And when you have the V8 engine, you have all these goodies that make it like a good environment to run your JavaScript in. So not only do when we're running it in the browser, we get access to the V8 engine and the compilation, the memory management, the garbage collecting, we also get access to all these web APIs and the ability to pass stuff off to really meaty programs or really meaty sets of tools like LibEvent, right? And so LibEvent is the cornerstone of the event loop in the browser. LibEvent is actually different than LibOv. LibOv is what helps us have the event loop in Node, but in the browser we have LibEvent. And I always feel that you can tell how serious a tool is by looking at its website. Should we install LibEvent? No, we don't have to because we get access to it by it being in the browser. So here's LibEvent's website. Yeah, they got this one.

There's some nerd stuff, exactly, though. They got this one. You on one. All right, on one. You do you. Thanks. Thanks. Whoo. Thank you. All right. Whoo. Right. So we get the past stuff, the lib event, which does all the heavy lifting for us, right? As developers, I'm really thankful that I don't have to worry about this stuff, right? That I can just hand this off to this battle-tested lib event which will handle the event loop when I'm running my JavaScript in the browser, that we get access to all these wonderful web APIs, that my JavaScript runs in the browser, or it gives it access to the V8 engine, which enables my code to be compiled, to have memory management, to have garbage collection.

Like we get all this stuff just by running JavaScript in the browser. Right? And so we have to understand like how this is actually working and what's actually happening when we run JavaScript in the browser. And then we're gonna see that something very similar happens when we run javascript in node and so we have something called the event loop and the event loop monitors the callback queue and the job queue and decides what needs to be pushed onto the call stack now i'm using a lot of big words here i don't mean to misdisrespect but we now know what queues and stacks are and i'm going to show you how they play out when we to run our JavaScript in the browser, right? The event loop monitors the callback and job queue and determines what decides what needs to be put on the call stack. So we're gonna put stuff on a stack and we have queues and we have this loop. What the heck does all that mean? Let's talk about it. So first and foremost, I wanna just say again, Philip Roberts has a beautiful representation of this in the video. There's a sign for your homework. This is a simplification of their work. So if you want to see in much more detail, you have to watch Philip Robert's video. In fact, you have to, it's part of homework, but know that this idea and this concept comes from them and how they broke it down. And I'm using our past example with the console log in combination. So when it comes time to executing our JavaScript, we know that our JavaScript is single threaded, right?

It's single-threaded and we're gonna treat this single thread right now by using something called the call stack We are going to put stuff on to the stack And when we put stuff on to the stack The stack is what kind of data structure the stack is what kind of data structure Last in first out so the last thing on the stack is going to be the first thing out of the stack. All right, so when we run a program in the browser, when we run our JavaScript in the browser, there's always this main. And this main tells our JavaScript to run. And then once this starts running, we're gonna have an event loop that comes by the way of lib event that runs consistently. So it'll loop and then it'll loop and then it'll loop and then it'll loop and it'll keep going. And so give me a little bit of room here, a little bit of flexibility. This isn't 100% what's happening, but it's meant for demonstration. So our JavaScript has been told to run. And the very first thing that runs is this lovely console log. Right? This lovely console log gets put onto the call stack, right? And since it's the first thing in, sorry, it's the last thing in, it is going to be the what? If we look at this stack, here's our pancakes that are building up. Our pancakes are building up this log of house one since it is the last in, it is the first out. So once our loop executes, right?

Once this event loop executes, what we're going to wind up seeing is we're going to pull that log off the stack and we will see in the console house one. Now the next thing that happens is we try to run the next line of code which is the setTimeout. And so we looped around and once again, we're back at the call stack and setTimeout is the last in, so it's going to be the what? First out. Now, can JavaScript execute this off of the call stack? Like, can it run it directly from the call stack? What do we know about setTimeout? No, we know that setTimeout is a web API. So the event loop enables us to hand this setTimeout to the web APIs, and that's exactly what happens. It gets handed over to the web APIs, and this could take forever. This could take an hour. It does not matter. It could take a full hour. We've handed that off to the web API. It's going to do its thing now the event loop runs again and We have this last bit of code.

That's going to execute and so now on the stack is The third console log Right. It's the third console log right now since this log is the last in It's going to be the what? First out. Does it matter that our setTimeout finished? Does it matter that our setTimeout finished? No, because when the setTimeout finished, it went to the queue. It didn't get added to the stack right away. When the web API finished, it went to this task queue or job queue. It's kind of different way of talking on. There's also like micro macro queues. There's a bunch of other stuff, right? But it goes into a queue and we need that to happen because the web API could have took an hour. It could have took one second. It doesn't matter. So when the web API was done, it doesn't immediately, right?

Doesn't immediately go onto the stack. it goes into the queue, all right? Now, we can see that there is this lovely log that is on the call stack. So what's going to run first? Last in, first out. So console log of house three is going to execute, And we are gonna see in the console we're gonna see in the console house three now the event loop runs again and It notices that there is nothing left on the call stack and So if there's nothing left on the call stack, what do you think actually happens? This lovely event loop looks to the queue. And we know that this setTimeout, this promise, right? This promise that came from the web API, it's in a queue. And a queue is what kind of data structure? it's a first in first out. So that means this queue is a first in first out. That means eventually this is going to get added. So this is the first thing it's going to get added to the call stack. Once the call stack is empty, right?

Right, it's added to the call stack because the call stack is empty. And so now, we have the promise that came from the setTimeoutWebAPI, right? And since this is the last in, it's going to be the what? First out, beautiful. So then it'll eventually run on the last loop and we'll see house two. So this is why, right? This is why, this is why even though there's a zero delay, it's still console logs to last right now a lot of folks are saying what happened to main that was over here what do you think happened to main if the stack is a last in first out and the stuff that is in the queue doesn't run until the stack is done what happened it finished it ran right it was it went through it ran and then once the call stack was empty there was nothing left in the stack right once it was empty nothing left in the stack well then we went to the queue to start putting stuff on the stack but stacks are a last-in first-out structure so there's no way that we could have added stuff to that stack right we couldn't have added stuff to the stack right until it was done And so this is where that delay is coming from. This idea that when we use setTimeout, it got added to the stack, the event loop ran, it took it off the stack and handed it to the web APIs. And web APIs, we could have dozens of web APIs that are happening all at the same time. Or we could have a bunch of web APIs that are all happening at the same time, right? And as each web API finishes, where does it go? Right, like this one could finish, and then this one could finish, where are they, they're all going to the queue. So let's say this is one, two, three, and four, right? Two could finish first and go into the queue, and then we have two. then an hour later, one could finish and that could go into the queue.

And then 10 minutes later, three could finish and that would go into the queue and then four could finish, right? It doesn't matter. The beautiful thing is that all this asynchronous stuff that we've just been handing off to the browser, the reason it works is because it's not affecting the stack. When it finishes, it goes into the queue And once the stack is empty Then we can go look in the queue I was running back All right, whenever our JavaScript starts running, we always have this main that starts the running, right? So the main is going to tell it to start running, and it's gonna tell the file that we have here to start running. The very first thing that gets added to the stack is what? What's the very first thing that gets added to the stack? Yeah, the first console log is gonna get added to the stack. So we'll see that, right? That first console log is added to the stack. The event loop runs and we see that the log is on the stack. And so it's time to execute that console log because the stack is a last in first out structure. And since this log is the last in, it's gonna be the first out. and we're gonna see that log be put into, it just runs, it executes, right? So we see that console log actually happen.

Now, the next thing that runs, right? We come around and we see this next line of code, the setTimeout is gonna be put on the call stack, right? Have we gotten to, like, the thing I think people are getting tripped up is right here. Have we had enough loops for main to come off the stack? Right if after each loop it runs the next line of code, right? It's single-threaded right if we're if we just ran once we have to grab that next line of code The main hasn't had a chance to come off the stack yet. It won't have a chance to come off the stack until it's empty Right, so we looped around and we're gonna grab this next line of code the set timeout goes on to the stack Right, so the loop comes around it's time to execute the setTimeout, but can JavaScript handle the setTimeout? No. So it gets handed off to the web API. Beautiful. So now this setTimeout is doing its own thing. It could take an hour if we wanted it to. It does not matter. It's off in the browser doing its own thing, doing its own asynchronous thing. It's having fun, right?

It's having fun doing its own thing, but the event loop don't stop, doesn't stop. So now it's gonna go grab the next line of code, right? It loops and grabs the next line of code. And so that next line of code is that console log that comes onto the call stack. Now it just so happens that since there was no delay in our set timeout, that that setTimeout resolved very quickly, right? That setTimeout, it went off to the Web API, but it resolves so quickly because it was zero. There was no delay. So the Web API resolves it so quickly, but it can't add it to the call stack. Anything that comes as the result of the Web API, all those promises get put what? All those promises get what? Put what? Get put in the queue. Exactly. And we only go to the queue when? We only go to the queue when?

When the call stack is empty. Exactly. So, we loop around, the loop ignores the queue, it looks at the stack and says, oh, this console log is on the stack, so time to execute that console log, right? It loops around, it sees that main is there, it gets, main execute doesn't really do anything, right? The main executes, right, it doesn't do anything, it was just there to start the JavaScript file, but there's nothing there, so that executes, And then it comes around another time and now it sees that the call stack is empty So on the next loop It looks at the queue and says alright Give me the first in because the queue is a first in first out structure, right? There's nothing in the stack It's time to go to the queue since the queue is a first in first out structure it grabs the setTimeout or whatever result came back from the setTimeout. Remember, Web APIs return a what? Web APIs return a what? Yeah, back in the day it would be a callback that was sitting in the queue, but now it's a promise that's sitting in the queue. And so the event loop says, all right, there's nothing on the stack. We're gonna grab the first The first thing that's in the queue and we're gonna put that on the stack All right loop runs around it executes that promise that is sitting on the stack and we see console log house 2 Right, then it runs again to check to see if there's anything else new in the task queue And it's not so we're kind of done for now But the cool thing is we could have handed off a lot of stuff to web APIs and they all could have they could have all asynchronously finished at different points in time and be put into the queue at different points in time and then as the call stack empties, we start putting stuff from the queue onto the stack. You get another example of the fetch API, it would be the exact same thing with a fetch, where if this line was, let's say a fetch, the fetch would be put onto this stack, the loop would come around, JavaScript wouldn't be able to execute it, so it would pass it off to the web API. The fetch would be here, waiting for data to come back from whatever, right? Eventually the dog CEO API responds. It takes that promise, right?

That has all that data in it. And that gets put on the queue. Eventually the call stack is empty. And we grab that promise from the queue and put it on the stack. Stack never waits. JavaScript is single threaded. It is synchronous. It cannot wait. The event loop is handling all this asynchronous stuff for us. Ooh, good question. What if, what if house three had a delay of two seconds? Would it still log before house two? So let's see if we had. If we had like a actually I'm going to say this for Sunday, I'm going to say that I don't want. I don't get two people in the head.

I don't get to it. I'm going to say this for Sunday. It's a really good question. Ask that question Sunday. I don't want to get people too lost to the sauce, but it's a really great question. Think through it. I want you to think through this for homework and then come on Sunday will do it. What if this? Add a set timeout of zero seconds as well. What if it had three seconds, right? Think about it. When does it get pushed to the web API? And where does it show up in the queue? Which thing would show up in the queue first, right? Because remember queue is a first in first out structure.

So even if they're both web APIs, what gets added to the queue first? Because whatever gets added to the queue first is getting added to the stack first. It's a really interesting question. Mm hmm, so I don't want to. I know where I pushed you. If you want to have that thought experiment, go for it. Come on Sunday. We're going to do all. We're going to run this all back on Sunday. If you're like Leon, you did it two or three times. It's still not still not there. Come back on Sunday. We're going to run through this a couple more times. We'll do a bunch of other examples with it and play with it. I have a little bit more detailed version of this.

And then remember your homework, Your homework is to watch Philip Roberts video that goes even deeper on this. And so I think you're going to have a lot of fun learning a lot of cool stuff. All right, so underneath the hood, this is what's happening. Let's go. Like you now understand, like if you took every, every developer that writes JavaScript, you're now in a percentile of developers that, that just doesn't understand how this stuff works. I guarantee there are so many developers that are writing JavaScript professionally that have no idea that this is what actually is happening underneath the hood, and this is our competitive advantage, folks. It's how we eat their lunch. You're now elite, exactly. All right. Time to talk about some backend, baby. All right. So now we understand what's happening in the browser. let's talk about the back end, all right? Does JavaScript have access to the DOM built in? Nah, nope, mm-mm, nope.

JavaScript needed the web APIs to handle all that asynchronous stuff and a bunch of other stuff in the browser, right? Without the web APIs and without the event loop handing that stuff off to the web APIs, wouldn't be able to do the things that we were able to do. So JavaScript is a language that can only do what the hosting environment allows. And when we're running JavaScript in the browser, the browser becomes our hosting environment. Now, what do servers need? Chat, what two things do servers need to do their job? Remember, we make requests to servers and servers deliver responses. What two things do servers really need? They need network access and they need disk access. If they can't hear those requests that are coming off on the network and respond to them. It's not a server It literally can't serve and then if it can't like grab the files that it wants to serve. It's not a server It can't live up to its name of serving if it can't listen to the requests to generate a response and it can't live up To its name if they can't literally grab the files to serve so servers need disk access like access to the files on the hard drive or the solid state drive, and they need access to a network, like access to the internet to hear those requests, to generate those responses. It doesn't have those two things. It can't be a server. Cool.

So what if there was a hosting environment that allowed JavaScript to have disk and network access? Because does JavaScript by itself have disk and network access? No, five seconds. So what if there was a hosting environment that allowed JavaScript to have disk and network access? It Hey, does this work? Node.js baby. It's the environment, right? The environment that enables us to have access to the disk and the network. That's a node. Now, when we go to node's website, they have this like really bad thing here. I just don't get like, if you like you all, hold on, let's get in here real quick. You were all going to go out into the world, right? You're already badass developers. You're going to become even more badass. You're going to eventually be in charge of large projects.

you're eventually going to create wonderful open source libraries, please write what your thing does in plain language, so that your fellow 100 devs know what the heck you're talking about. You can have the nerd version below, but give the real human version above, so that we actually understand what the heck is going on. No more disrespect. The disrespect stops here with us. Cool. So Node.js is a JavaScript runtime built on Chrome's VA. Oh God. The same shit that lets you run JavaScript in the browser can now be used to run JavaScript on servers, desktop, and pretty much anywhere else these days, right? So it's just a place to run your JavaScript. And so JavaScript runtime just means a place to run your JavaScript and it uses Chrome's VA engine. So the VA engine that we used in the browser that helped us with the compilation That helped us with the memory management the garbage collecting all that stuff. We can now use that like on the server Now When we're doing node, right? When we're using node the VA engine is doing all the heavy lifting remember We write JavaScript that's human readable, but that has to be broken down into something that the computer can understand. And so V8's doing that heavy lifting. And it's not really a compiler, we call it an engine for a reason.

And the reason we call it an engine is because it does more than just, it's more than just a compiler, right? It's a friend, it's a confidant, right? It's a lover. And it also does a lot of other stuff for us. It handles our memory management. It handles our garbage collecting, right? So it's way, way more than just the compiler or interpreter, whatever, we're not there yet, but we'll get there soon. It does so much more. All right. Now, just like the browser, the other environment, right? Right? Just like the other environment, the browser, Node is a new environment that comes with a bunch of stuff. Right? It comes with a bunch of stuff. So the browser came with web APIs.

Node comes with a bunch of modules. It comes with built in libraries or collections of functions that do all the heavy lifting. So the HTTP module is basically just an object that has a bunch of functions in it, right? that people have written that help us access the network. The FS module is just an object with a bunch of functions in it that help us like get files off of the hard drive or a solid state drive, whatever we're using. And we get access to millions of other packages via package managers like NPM, Yarn, or wherever else the cool kids are using these days, right? So you're not limited to just the core modules that come with it, But you can install and get access to all these other modules that you can get through npm now Since we're not running javascript in the browser. We don't get web apis anymore Right Right. We don't get we don't get web apis anymore because we're not running in the browser But what we do get are c or c plus plus apis And so the cool thing is we're writing JavaScript that JavaScript is being broken down into something that the computer can understand by the V8 engine. But then we're getting access to all these other like really fast, like super fast, super well-built out things that enable us to do the same stuff that like the web APIs did in the browser, right? But this is where when people say node is fast. It's coming from this right it's coming from this It's that we're sitting on the shoulders of Giants the stuff that node is using is really like CNC plus plus Underneath the hood and we're gonna notice some things right so it's a little bit different because in the browser We're using lib event, but in Node we're using lib of right so it's a different implementation of it where things are similar, but they're slightly different because the environments, the hosting environments are slightly different. In the browser, we had web APIs, and then in Node, we get C and C++ APIs, which makes Node a really, really fast language. And we get all the same goodies that we're used to, like lib of, instead of, it's lib of instead of lib event, right? We get all the wonderful async stuff.

We get all the event loop stuff. It's just handled by slightly different things. Cool. All right, so I asked you to install Node. If you haven't, you're gonna have to do that if you wanna do the homework. We talked about last time about release schedules. It's up to you what release you wanna start with. 16 is totally fine, 18 is totally fine. It won't stop you from participating in this class. Go with whatever release you wanna go with. I'll be using 18. And then we started with this very simple Node server. So with our very simple Node server, we used the two core modules. We used the HTTP module to set up the server to listen for requests and then help us generate a response. And we use the FS or the file system module to get the HTML files off of our disk, right?

And with these two modules combined, we were able to build a very, very simple server. And with this very simple server, we saw that the HTTP module came with a create server method. So somebody has already built out a method that creates the server. We told it what port to listen on. And then whenever somebody went to that local host 8,000, whenever they went to that port, whenever they went to that URL, it made a request to our server. And that request, when we heard it, we went to our file system, we found the HTML file and we responded with it. That's all we did. We just heard a request and we responded. Now, do I have this memorized? No, I'm pretty sure like I could type this out right now, but it's not something that I have committed to memory. It's not something you have to commit to memory. This is not something that you would really use every day. We're gonna get to something called Express next week that makes this a lot easier. A lot of this like really like detailed code that we're seeing here, like handling the header and writing the data and responding express handles for us. And so creating the server express will handle for us.

Listening to requests and handling response express will handle for us. So this is like, this is some nerd stuff right here. We're talking about like very, very simple base level stuff here using just the core modules of node, we were able to build a simple server and become full stack web developers. We were already software engineers, but as soon as you ran this simple server, you became full stack. Cool. So tonight we still have like 22 minutes or so. I want to continue to, right? I want to continue to build off of this very simple server idea. and we're going to look at a more complex backend, right? So we're going to look at a more complex backend. And so let's go ahead and look at a more complex backend. And I'm going to close what we have here. And we're going to look at this node backend simple JSON. And so if we open this up, we have a lovely server JS. We see we have some HTML files that we can serve up.

We got some beautiful things here. So to run this node file, what do I have to do? I've opened up in VS Code. What do I have to do to run this node file? Yep, node server.js. All right. Now something happened here. We got an error. If we look, it says it cannot find module. When you get the cannot find module, what do you think just happened here? What didn't I do? There's two things that could have happened here, right? Two things that could have happened. One, I didn't install my modules, or two, I am in the wrong directory. So what happened here is I am in the wrong directory.

I'm still in my class folder. I have to go into my node backend simple folder for this to work. So cd node backend simple JSON. And let's try again. Now, instead of typing out node server JS again, what could I do? What could I do? Service, help me out again. I could just hit the up arrow. Boom. There we go. Hit up twice and there you go. Node server JS. All right. I got my REPL. Let me move this over a little bit here.

My REPL sitting there, which means that my server is still running, right? Now, my server is running right now. If we go to, let's find the port, localhost 8000. We go to localhost 8000. We see that it served up my site and it's working. Now, yours might not work because if we look, If we look, you can see that it's requiring some of the core modules, but it's also requiring this figlet thing. What the heck is figlet? Right, what the heck is figlet? Let me show you what figlet does, and then I'm gonna show you how to install it. So here I'm on my localhost 8000. Let me go to a route that does not exist. right? Hopefully that that's not a route that exists. And so let's go ahead and hit enter. And I get this lovely 404, but look at the 404.

It's beautiful. That's that's some good ASCII art right there, right? So what figlet does is figlet takes in a string and turns it into ASCII art. But that's not something that comes built in with Node. And so if you want to use figlet, we would have to install it. And so I already installed it because I of course ran my code before class, but you would have to do npm install figlet. And then once you did npm install figlet, you would now have access to all the modules that this file requires. Cool. Let's go ahead, is my server running right now? I mean, if you install it twice, nothing, it won't really do anything. My server's not running right now. How do you know? How do you know my server's not running right now? Yeah, I better go catch it. Because I don't have the, like the, I have my REPL back, right?

if we look, I have my place where I can type. So if I run it, you see I don't have the place where I can type back, right? You can see, I don't have my ability to type there anymore. So that's how I know my server's running right now. So let's go catch it. And let's see what this server can do. We already saw that it has a 404, but we have this lovely main page. We also have some other pages that we can go to. Oh, other doesn't, sorry, it's other page. We saw the 404 again, other page. We have other other page, other other page. So these are all pages that the server is serving up. And the cool thing is I also have a very simple API that I built, right? A very simple API that I built to where if we enter in any name except for one, we get something back. So let's go ahead and enter in John.

Uh, does anyone know who John is? John is Bob's evil brother. Yeah. John is Bob's evil twin brother. Uh, so if you see the, the red, the red emotes, those are John emotes. Uh, so yeah, John is Bob's evil twin brother. So if we ask for John, we get unknown, unknown, unknown. Any relation to Papa? I don't know. Maybe that's where the hate all started. Maybe, oh, that's the lore expanding. Right? So we type in John, we get unknown, unknown, unknown. Let's put in somebody that we all know, Leon. And I'm gonna put in Leon and I get back, Oh, Leon, boss man, baller.

I wrote the API, so I get to make it say whatever I want. All right, so humble. But if we put in any other name, all right, put in some other name here. Let's put in another, what's somebody big that everyone would know? Somebody said Obama. Simba, there we go. Put in Simba. No, no, no, no, no. We put in Leon. Leon, boss man, baller. All right, let's take a look at this code. So we saw a lot of stuff that's happening here. We have not only an API that we're getting responses back from, we have the ability to serve up multiple pages, the main page, other page, other other page. When we request pages that don't exist, we get a 404 and this is all working. Let's go and take a look.

So once again, we are using the HTTP module to create our server. So all of this here is creating the server, right? All of it's creating the server, but what we're gonna have to do is we are going to have to tell the server what happens for every single request that is made. So when we go to the main page, what route are we hitting? Like when we go to localhost 8,000, what is our route? It's forward slash, right? So what we're gonna do is we're gonna look at what page we are on. So this hot mess of a string here, what this tells us is what path we are on. So when we go up here, localhost 8,000 is this path. Other page would be this path of their other page would be a different path So what we're able to do is whenever somebody makes a request to our server We were able to see what path they are requesting If they are on the main page We are gonna send them what what are we gonna send them if they're on localhost 8000? What are we sending them? We're sending them the index.html. Now let's brain blast back to our beginnings of HTML. And when this HTML file loads, just by looking at it, what else do we know it's going to load? It's gonna need to load CSS.

It's gonna need to load JavaScript, right? And so, does that come for free or what do we need? Does it just magically know how to do this? Does it magically know how to give you CSS? Magically know how to give you JavaScript? No, it has to be part of the server. So if we scroll down past all this stuff, we can see that, oh, if they ask for the CSS file, boom, send them the CSS file. If they ask for the JavaScript file, boom, send them the JavaScript file. If they ask, right, if they ask for the other page, well, we send them the other page.html. If they ask for other other page well boom here we hand them the other other page HTML if they ask for a response from our API Here is all the code that handles the response from the API Right so that means in our client-side JavaScript there's probably oh my gosh look at this async function. Let's go Oh, look how clean this is with the async, right? We know that we're making a request, right? But notice that there's no URL here, it's just the slash. We're making a request to our own server. We're making a request to our own server.

And our server is set up to hear that request. It's set up to hear that request and know what to do. Now, this looks like a hot mess because it is a hot mess. This is what we had to do back in the day before we had Express. Every single route had to have a response and we had to code it all out. It was messy, right? It was messy. It was ugh. I don't like this. But Express rides in on their white horse and saves the day. Express comes in and saves the day. So we don't have to like actually write all this stuff. Now, I'm gonna ask you a question. Could I write all this from memory? Could I, myself, that's been coding 10 plus years, write all this stuff?

Hell no. If you're looking at this and like, Leon, I have no idea how you would do this, I don't know how I would do it either. I can't write this. I have no idea what, I would try to write the first head and I'd be done. Right? No way. It's just, it's just not something that I've committed to memory because I don't have to express those all this heavy lifting for me these days, but what I should be able to do is read through this and know what is happening, right? So that's what I need you to do. I need you to read through this, right? And figure out what is happening. And that is your homework. Before Thursday's class, I need you to read through this file and figure out what the heck is going on. Figure out, all right, well, if the page was this, we're sending the HTML file. Figure out what's happening in this hot mess of an API request. Play with it, right?

Get lost in it, right? Watch the videos that were assigned for homework. A lot of this stuff was covered. Go back and watch my and Wolf's stream team. They already went through this. So if you get lost, you know, the stream team is here to help. So my Wolf already walked through all this. It's, it's on their stream from past Sunday. They talked through all this, but I need, before you watch my Wolf's video, I need you to spend time on it on your own. One of the first things most of you are going to do, one of the first things you are going to do on the job, is they're going to unleash you on a bunch of old code and tell you to make it better. They're gonna tell you to make it more modern, right? They're gonna tell you to get in with the old stuff and make it better. So guess what we need to start practicing as part of program. I'm giving you a bunch of old code. First step, figure out what the heck is going on.

Second step is, how would you make it better? Would you do a switch case? Would you do something else, right? And then once you feel comfortable that you've looked through it, you have an idea of what's happening, you've maybe come up with an idea too to figure out how you might improve it, I would watch May and Will's video to see how they work through it, and then come to class on Thursday where we dig in deeper, all right? That's the homework. You got about a seven minutes of time to work through it. Well, that's the homework. Don't let this block of code scare you. You have to get used to seeing a hot mess of code, jumping in the muck and figuring it out. This is literally what you will do for the first three months on the job at a lot of companies. You're gonna get a hot mess of code. You're gonna have to jump in, go line by line, and figuring out what the heck is happening, seeing the patterns, playing with it. And when you get stuck, where do you go? When you get stuck, where do you go? You go to Discord.

You go to Discord, you ask questions. Hey, I've tried my hardest. I Googled my brains out. I could not find it. You ask on Discord. You watch Mind Wolf's video from Sunday, right? You have to get better at this part of the process This is an important step in your growth this idea of giving a hot mess of code Figuring out what's happening getting into it getting into the muck Get lost in it play with it figure out what the heck's going on. And then we come back on Thursday We'll go deeper into it. I'll explain everything I'll go line by line for you But you got to put in that work first because this is something you're gonna do in the job a lot And then if it still doesn't make sense you come back on Sunday And we're gonna spend a lot of time on this stuff again as well. Oh

End of Transcript