Oops, You're a Programmer Now | a Guide  In this modern age of AI, more and more people are writing computer programs or asking AI to write computer programs. And if you've done this, you may have start to realize there are limitations. And ultimately, you've kind of just been tricked into becoming a programmer yourself. It was sold as we can just tell computers what to do and it'll create these programs for us. Everything will be fine. But that is absolutely not the case. And in this video, I want to help you because you've already shown interest in creating things with computer programs, whether or not you're understanding what is actually being created. And what I want to do is go all the way back to the beginning of of my knowledge and understanding of computers and hardware and software and and how all of this stuff connects together and basically just give you a road map because you don't know what you don't know. it can be very hard to figure out the right questions to ask when you have decided that yes, I want to know more about computer coding or or software or hardware or or anything else. So this video is a road map. It's going to be high level at some points, low level at other points, but basically I'm going to give you lots of different launching off points so that if you actually do want to put in the work and learn more and dive deeper and start to understand this stuff that AI has just been doing for you, this video is absolutely for you. If you already know a lot of this stuff, you might find something new or interesting that maybe you hadn't been exposed to before. So definitely check the timestamps in the description. And also if you know somebody in your life that has started to vibe code or maybe use AI to do more technical things and they seem like someone that could probably benefit from understanding a little bit more about how all this stuff works, share this video with them as well. If all that sounds good, let's dive in. My name is CJ. Welcome to Syntax. Now, the first thing I have for you is more of a mindset shift, and I kind of want to change how you see and go about the world. And the idea here is that computers are all around us. There's computers absolutely everywhere. So, you are watching this video on a computer of some kind, whether it's a laptop or a desktop or a phone or even a TV. Modern TVs are very much computers. And so as you go about your life, try to identify computers. For me, it's when I get into my car in the morning that has a a computer that's running the the touchscreen system. If I'm going to ride the train, that kiosk is a computer that's running a program that's going to sell me my train ticket. If I go to the store to buy something, the selfch checkckout is a computer that I'm interacting with. If I go to buy food at a restaurant, a lot of times there's a computer running the menu that uh is displaying the menu items. So computers are absolutely everywhere. That's not a non-exhaustive list. And once you start to see this, the world starts to open up for you because as we'll learn in the next section, computers run on code. And if we can write our own code, we can control the computers that are around us. And if the world is controlled by computers, we can control the world. So that's that's the first thing that I want to leave you with is computers are everywhere and start identifying them. Now, to get you started on some resources, just head to the Wikipedia article about computers. Uh the history of computers itself is fascinating. I I didn't even mention it, but game consoles are computers as well. And then of course you have the computers that you might not not have seen before, the big ones running in servers, but at the end of the day, those are just bigger, beefier versions of the thing you might have at home or might have in your pocket. So this is a fun read just learning about the history of computers. And I'm going to recommend a book called Code, the hidden language of computer hardware and software. But this book is really good even for non-technical people. So, if you've never even been exposed to any sort of this technical stuff before, the author does a really good job of breaking down how computers actually work under the hood. And in order to write your own code, you don't necessarily need to know all of that lower level stuff. But if you're like me, I like to figure out and learn how things work. So, this book is really good for that. And the Wikipedia article is also just a jumping off point for all of the things about computing and what computers are and the history of computers. Now, if the idea of computers really interests you, you can start to learn more about computer hardware. So, this is the actual physical thing that powers the computer. Here on the Wikipedia article, you can see a CPU board or things like an actual computer tower. This is an older one compared to the ones we see these days. But one of the ways that I got into learning about computer hardware was just building my own computers. And these days, it is so easy to build your own computer, especially if you're really into computer gaming. You've probably seen builds like this, and you can actually purchase these offtheshelf pre-built, so you don't have to worry about figuring out the the components of it all, but you can also build your own. So, pcpcpartpicker.com is fantastic for this. And especially, even if you're not going to do it, you can just go in and start to learn about the parts and pieces. So, every computer needs a CPU. That's like the brain, and you can see what are the the modern CPUs and how fast are they, and you can add it to your build. And then a CPU plugs into the motherboard. That's the thing that connects all of the other components. And so on this site, once you've chosen a CPU, it's going to find a motherboard that is compatible with that CPU. Um, and so we could choose one of these. And then from there, we can choose our memory. And so RAM in a computer or random access memory is temporary me memory. That is things don't stay there forever. Your computer uses this RAM when it's running programs and running software. So having more of it allows you to run more things at any given time. And so we can add some some memory to the computer. Uh, and then also storage. And so if we want to store files that exist for a long time and don't just disappear when we turn our computer off, we need things like a hard drive. And these days, hard drives have gotten tiny. So this is actually known as an M.2. You might not have even seen these before, but they're inside of computers. And that little thing right there can hold two terabytes of data. They're also hard discs. So these are things that have like a spinning plate. You can find ones in a similar form factor that don't have a spinning plate, but any data stored on here is going to stay there even when the computer turns off. So, if you want to have lots of videos and lots of programs installed, you're typically going to get a lot of storage from there. And then you need a video card. So, the video card allows us to play games with interesting graphics or watch 4K or 8K videos. And the video cards themselves have memory. And I I could go on and on, but if the idea of building your own computer from scratch interests you, I highly recommend it as as a as a pastime because once you get into it, you'll you'll start to learn about all the different ways you could do it and all the tradeoffs. And there's some really fun builds that that you could get into as well. But even though this has nothing to do with AI, AI itself is running on computers. Um, and so you might have seen the video that PewDiePie did where he built his own custom computer and he just filled it with lots and lots of graphics cards. Now, the one that he chose was not this one. I think his graphics cards were anywhere between5 and $10,000 a piece. So, his build is very expensive, but you could build yourself a miniature version of that if you find a graphics card with quite a bit of built-in video memory. So this is the next launching off point actually learning about what parts and pieces make up a computer. Now another route you could go down is learning about single board computers. And so this is a Raspberry Pi. I have so many of these little things and this is a computer and it has these things here called GPIO. So you can plug LEDs or switches or all kinds of electronics components into it and you can control them and you can customize this thing and uh it's really cool and you don't have to piece it together. This is an all-in-one board. It's got memory. It's got a CPU. Uh the storage itself is actually just this tiny little SD card. So all those parts and pieces that we talked about are just tiny and embedded on this thing. So these are really great for learning. Um and you don't necessarily need to get a Raspberry Pi because Raspberry Pies have actually gotten pretty expensive. You can just look into this idea of single board computer because there's things like the Orange Pie or the Rock Pi. There's a few others out there that are either cheaper or similar in price but with more features. Um, and this is another great way to get into computing and especially if you have a smart home. So, one of the first things I did when I got one of these over 10 years ago was I made it so that I could open and close my garage door remotely. I didn't have to buy anything. I literally just hooked it directly up to the GPIO and connected it to the internet. Um, I've also used these to control lights and switches. Of course, you could buy things off the shelf, but it's really fun to build it yourself and and learn how to like write computer programs, which we'll talk about, that then communicate with the physical world via some hardware. And then another launching off point is Arduino. And so these are also single board computers, but they're a little less powerful than something like a Raspberry Pi. This is a full-fledged computer that can run an entire operating system and programs, which we'll talk about in a second. And so it can do a lot. But this runs a single program. So you write a program, send it to this device, and that's the only program running on this device. And so these are a lot cheaper. Um, and you can do similar things with them, but they're they're single purpose devices. But all of these things are great ways to getting in and learning about computer hardware and really just getting hands-on with all this stuff. Now, the next piece of this puzzle is software. Now, we have the hardware, right? It's in the physical world. We can touch it. We can feel it. But software allows us to make these computers do interesting and unique things. And every single one can do different things because we can all write custom software. Now, you probably have heard of this as computer code, but you've also probably heard the word app or also known as application software or a mobile app or a computer program. These are all words for the same thing. It is essentially software that is running on the hardware. So, every morning you might look at your phone to tell the time that's running the clock mobile app. Every morning you might open it to Tik Tok or YouTube or Instagram. Each one of those is an app. Each one of those is software. It's a computer program. and it turns this physical computer hardware, whether it's this or whether it's your phone or a watch or whatever else into something that makes it into a multi-purpose device that can do a lot of things and interesting things and unique things depending on who's using that particular piece of hardware. Um, and so this here is where we're going to spend a lot of our time is is talking about how all of this fits together. But this is basically the world that you've gotten into. When you ask AI to build you a website or write code for you, it is writing software. And that software that it's writing is the same software that you yourself could write. There's nothing special about it. It's just the fact that we let an AI do it instead. So this kind of brings together this whole shift in worldview, right? If everything around us is a computer and everything around us is running software, well, if I learn how to write my own software, I can control everything around us. Um, or I can ask AI to write the software and it controls it. But as you can see how passionate I am about these various things, uh you too can potentially unlock that passion. And in my opinion, it's harder to get that passion when you ask someone else to do something. It's like asking your brother or your mom or your your your cousin to uh go have fun for you. To me, that's what it's like to ask an AI to do something for you. Um and so when we learn about how all of these things work from the ground up, we can start to control the world around us. Okay, so we have computers which are made up of computer hardware and that runs software which we can write. And how does all of that work on a single device? Well, that works with an operating system. So this is also a piece of software or also known as system software that can run multiple programs. So this is why your phone can run multiple apps or your laptop can run multiple apps. It has an operating system. So this is the next thing to learn about. You technically don't need to dive too deep into this unless you're just interested in learning about how all of this works because at the end of the day, you're really only thinking about the operating system if you're writing software specific for that operating system. And there's ways to write software that run on multiple operating systems. But as someone getting interested in computers and programming, you might start to develop a preference over one operating system over the other. And when I say operating system, I mean things like Microsoft Windows or Mac OS, which comes from Apple, or Linux, which itself is kind of like a family of Unix based operating systems. Um, I laugh because it gets complicated. Or things like iPad OS, which is the operating system running on an iPad, or iOS, which is the operating system running on an iPhone. But now they've converged and I think they're running the same, and eventually MacBooks might even run the same ones, but at one point we're distinct operating systems. Another one that's pretty common in schools is one called Chrome OS. And so this is usually on Chromebooks. And Chrome OS is actually based on top of Linux. So it's a Linux variant or if you have an Android device is probably running the Android operating system. So the reason I mention all of this is once you start writing computer programs, you're going to be writing them for different operating systems or for multiple operating systems. And it's good to know what is actually running your computer. And like I said, develop a preference over which one you'd like to use on your desktop computer where you're going to be writing these computer programs. So personally I like to use Mac OS. A lot of people like to use Microsoft Windows with a thing called Windows Subsystem for Linux which lets them do more Linux type things. A lot of people like to use a Linux variant called Ubuntu uh which is Linux but has its own preferences about the desktop environment. And a lot of people also like to run Arch. You might have heard the meme I use Arch by the way. So Arch is another version of Linux. All of these are operating systems and really all I'm saying to you is develop a preference. Like pick one and learn as much as you can about it. And personally, I didn't pick one. I I know a lot about a lot of them. So, when I was in college, I actually had a triple boot system. So, it was a MacBook that would boot into Mac OS, but I could also boot it into Windows and also boot it into Linux. And I loved just learning about all the different ones and also learning how to do a thing called try booting. Um, but you don't have to go that far into it. Pick one, learn about it, because this is the software that's running all of your other software. Now, in terms of resources for learning about operating systems, first I'm going to point you to this documentary, which is fun. You just sit back, eat some popcorn. In this documentary, Revolution OS is actually about the creation of GNU and Linux and open source and the free software movement. So, that's the other aspect of all of this operating system stuff is this idea of closed source or open source. But, Revolution OS is very entertaining and kind of takes you through this history of creating Linux, the the open source operating system. And you can watch it for full and free on YouTube, so it's not too hard to find. And uh yeah, it's it's just pretty entertaining. If you want to dive a bit deeper into how all this stuff is working, there's actually a really good video from Crash Course and they have a series on Crash Course Computer Science and a specific video on operating systems themselves. And so this gets into the history of why did we need operating systems and and how do they work? Um and while I'm recommending Crash Course, they actually have an entire computer science crash course which gets into software and hardware and all of these other topics that you might want to learn about in the world of of computer science. So again, you you just stop watching this video, go watch that. But really, my video is more of a launching off point to to point you to resources and and just really make you aware of all of these various things that you could be learning more about. Okay, the next piece of this giant puzzle that makes up this world of ours is computer networks. So we have computers, they run programs, they have an operating system. Great. But what if I have two computers? How can I make these things talk to each other? That can happen over a computer network. Um, and so here I have a a physical network that I'm about to build for you. So I'm gonna plug this computer in and then I'm gonna plug this computer in. And then both of these computers are in turn plugged into a network switch, which itself is a tiny computer um that allows these two computers to communicate. So computer networks are how you're watching this video right now. there is a computer somewhere else that has this very video that you're watching and it's sending it to your computer piece by piece and then your computer is receiving it and you're seeing it all happen in real time and and it the world we live in really really is an amazing place. Um and these are physical hardwired networks and that's how the internet came to be. The internet is the world's largest computer network. And essentially, there are buildings with massive amounts of hardware with and wires running under the ocean and running under the ground that connect all of these these cities and and buildings and and everything together. But there's also wireless technology. So, uh this is an older computer that actually requires an external antenna to be able to connect to computers wirelessly instead of wires. And uh more modern single board computers actually have the Wi-Fi chip embedded. You don't even need anything external. But that's just another way to connect computers together as well. So this is the other piece of the puzzle is networking computers and it's how all of what we're doing is made possible. Now in terms of resources, take a look at this computer network article. It it goes deep and there's a lot there's a lot in there. There's also this history of the internet Wikipedia article that gives a breakdown of basically how the internet came to be. The next piece of this puzzle is the worldwide web. And so the worldwide web and the internet are actually not the same thing. The worldwide web is built on top of the internet. But the worldwide web at the end of the day really is how you're able to watch this video that you're watching right now. It's how you're able to to text with your friends and uh watch Tik Toks and and do all the things you do on computers all day. It's because of the worldwide web. Now, before we jump into the worldwide web, there is a whole series of of abstractions, and I haven't used that word yet, but you will start to see that when I get handwavy over something, it's because we're we're kind of abstracting it away. We're basically saying, I know that this thing exists, but I don't have to worry about the details because it's just working behind the scenes. And so, the internet is just working behind the scenes. If you want to dive deeper, you can learn about communication protocols and know that the modern internet works over a thing called TCP IP. There's also this thing called the domain name system or DNS. I've actually done some videos on the channel here where I talk about how to make your own custom server which is a computer uh that is running the Linux operating system that we buy a domain and assign it using the domain name system. So all of those things we're not going to talk about in this video but those are other rabbit holes you could dive down to learn more about how all of this stuff connects together. And so the worldwide web is built on top of all of those protocols and is is really where we spend most of our time these days is inside of web browsers. And as you will come to learn, even when you're using uh a smart TV or your mobile phone and you're using a custom app, it actually is using protocols that are working across the worldwide web. So even though these are custom computer programs, they're communicating over the worldwide web, which is built on top of the internet. So again, I'm I'm trying to help you paint this mental model of the world, right? Every device that you encounter on a daily basis, whether it's your TV or your car or your phone or anything else like that, is a computer that has an operating system that has custom software that's running on it. And all of these things can communicate together because they're part of this big big computer network called the worldwide web. And that actually gets into the kinds of applications that I like to build. And so we can write computer software that works across the worldwide web. And that's why this is one of my favorite kinds of programming is because once you learn it, you can build things that allow people to to talk from across the world or send information to each other from across the world. Um, basically I love the worldwide web. I love building applications for the worldwide web. Now, if you've done any sort of vibe coding on tools like Vzero or lovable, these tools are building web applications. And so that's why we took this round path to get to the worldwide web because that is what you're doing when you are asking lovable or vzero or any of these other number of tools that will build apps for you to build an app. It's building a web application. And so that's what we're going to start to dive into is how do those things work? How do web applications work? What are the parts? What are the pieces? How could you do this if we didn't have AI to ask? Because at the end of the day, the thing that AI is outputting is computer code. And we ourselves could write that exact same computer code. There's nothing special about the the code that AI is outputting. And if we learn how computers work, how operating systems work, how computer programs work, how the worldwide web works, we can start to build our own applications and not need AI to do it for us or be able to customize or uh solve bugs when AI isn't able to do it for us. Now, before we get too deep into web browsers and web applications and programs and everything else, I want to take a step back again and go back to how computers work. Uh, because this is a fundamental piece that you're going to use throughout everything you do with computers. And it comes down to files. And the easiest way to talk about a file is to try to come up with a physical world representation of it. And so, I have it right here. This this is my file. and it has some information on it. It says hello world. And so it all starts here. This is my file. And computers are just made up of tons and tons of files. Everything is a file. Um it could be as simple as some words on a piece of paper or in a file. But from here, we can do a lot more because this is my custom crafted file with my own personal message on it. But they could get more interesting like my passport. My passport is a file. that has information about me and who I am and and and what I'm a citizen of. Um, also books could be files, right? So, uh, each one of these is itself made up of multiple pages, but the collection of all that information in those pages is a file that represents each one of these books. So, the fundamental unit of everything we work with on computers is files. And it actually is the same across multiple operating systems. So, I want to show you some examples. So, let's say you're on Windows, which a lot of you are. The files that we're talking about can be accessed using this little icon here. It's called the file explorer. And you may have looked at this, and the biggest gripe I have about computers these days is they try to make it so that you don't have to think about individual files. But as a programmer, we should think about individual files. So, you'll typically see recent. These are all the files that you've accessed most recently. But what I want to get into is how these things are actually stored and where you can put them. So, for instance, let's go into the documents folder. And in here, if I right click, I can say new and I'm going to create a text document. So, a document is another term uh that you might have seen to refer to files. Uh, but I'm just going to call this message like this. And so, this is a file and it's a completely empty file. If you look at the size, it's 0 kilobytes. It has nothing inside of it. And if I double click on it, it will open with the default program for managing that file. So, computer programs work on files. Computer programs themselves are made up of files, but we'll talk about that later. You'll notice this opened Notepad, which is the default program for editing text files. So text files are things that just have text inside of them. Nothing more, nothing less. It just has words and text inside of it. And so if I now save this file, that's actually going to update its contents. Right? So if we go back over here, we can see the size is has increased a little bit. And now my message is stored inside of there. So I close the program, but if I reopen it, there it is. All my data is inside of it. So this is a file. This is a very simple file. It just has some information inside of it, but everything is a file. Now, I want to show you this same thing on a Mac because it's similar, but slightly different. So, here on a Mac, there is a program called Text Edit, and it's very similar to that Notepad program that we used on Windows, but it allows us to create and edit text. So, here it is. I can open it up. And again, I can put a message in here. Wow. And now I can save it. And when I go to save it, it's going to ask me where do I want to put this thing? And again, they try to make things easy for you. They're like, "Yeah, let's just put it in documents." But you can be more specific about this. You can see where on my computer do I want to put this thing. And we'll talk about this in a second. But I'm going to call this message. And then I'll click save. And so now this file exists on my computer. I can close it. And then if I go to finder. So finder is the Mac program for looking at files. And if I go to documents, would you look at that? There it is. And if I double click on it, I can reopen it. The information is inside of it. So this is a file on Mac. Now the last example I'll show you is in Ubuntu. This is a Linux operating system. Again, it's very similar, but they have a program called text editor. And we can go in here and we can type our message. And then we can save it. So when I go to save, it's going to ask me where do I want to save it. We're going to put it in documents. We're going to call this thing message. And now if I close it, it's saved on my computer. I can go to files, which is the program that we use in Ubuntu to manage our files. If I go into documents, there it is. My information is stored inside of So, at this point, it's getting a little repetitive, but what I want to show you is that no matter what operating system you're on, or no matter what computer you're on, they're all working with files and everything is a file. So, we start with just basic information inside of a file. And then it can get more complex like I showed, a book is a file or a identification document is a file. So, that's a computer file. No matter what computer you're on, no matter what operating system you're on, we're all working with files. Check out this Wikipedia page on computer files and it talks about the etmology or the origins of why we use the term file. But now that we have files, we need some way to manage all of those files. And that comes down to a file system. And so a file system is the established way that any given operating system allows you to manage your files. And this is going to vary across operating system. But at the end of the day, as we saw with Mac, Linux, and Windows, the way that we interact with them is mostly the same. But what's happening under the hood, what's happening in terms of what we cannot see, that's where things start to differ. But right now, we don't have to worry about that. We're going to abstract that away and just talk about it as files. And so, now that you know this thing is called a file system, we can start to talk about what these labels are. So, we see documents, pictures, music, videos. These are all folders. And folder is another analogy from the physical world. So, if you haven't seen it, this this is a folder. Um, I guess you might have something similar that you use for your school files, your school documents. Um, but on a computer, we use the same analogy for being able to organize these files. So, documents is a folder that's holding that message document that I just created. But, of course, there's other folders like downloads and pictures and music and videos. Right now, this is a pretty blank computer. It doesn't have much on it. And each one of these is a folder. And the idea is you can put multiple files inside of a folder. So, got my folder. I'm going to take my document, my file here, and I'm going to put it inside the folder. Wonderful. It's now organized. I could even put a label on this, call this documents or whatever. But, as you can see, there's more space in here. So, I could also take my passport and put it in this folder. Or I could take a book and put it in this folder as well. And in the physical world, we're going to reach a limit at some point, but on a computer, you can put as many files as you want inside of a folder. And this allows you to stay organized. Um, and so this is a very messy folder because I have books and identification documents and other messages. But it's up to you where you store those files. So I would probably want to create different folders for different types of things. Now again, computers try to simplify this and and and abstract you away from what's actually happening here. But the best way to get a look at the files on your computer on Windows specifically is to go to this PC. And this is going to show you all of your drives. So this is where the information is stored. And if you click on your main drive, you'll see some folders. And this is known as the root of your drive. This is at the very top. And every other file and folder on your computer is stored within other folders that start here at the root. Let's take a look at Mac OS. And again, they try to hide it from you. They make it pretty hard to get to the root of our file system. But one thing we can do to uncover what's happening here is we go into settings. Then we can choose sidebar. And there's an option here for hard disk. I'm going to make sure that that's checked. And now over on the lefth hand side I can see there are locations and I can see the Macintosh hard drive. So if I click here I am now at the root of the file system for this given hard drive. And like I mentioned every file every folder on our computer is stored inside one of these folders for anything on our computer. Lastly I'll show you how this works on Ubuntu. I'm going to open up this file program. Again, they try to hide it from you, but the way to get there is to go to other locations. And for this given install of Ubuntu, I have a drive called Ubuntu. And this is where it all starts. You can see all of these folders. This is at the top level. Every other file, every other folder on my system is inside these. So, for instance, if we hop back over to Windows, let's say I want to get to that message file that I created. Well, follow me. It is inside the users folder because I have a user on this computer called CJ. And then if I go into that, I can see all of the folders inside of that folder. And if you remember, we stored it in documents. So I can click on that. And now we're at the actual location where that message is stored. Now, one thing you can do is if you click in the top here, you can see what's called the file path. This tells you exactly where the files are on the computer. And you can see it starts at the drive. In this case, the drive is called C. And then it goes into users and then the username CJ. And then a folder called documents. So each one of these things separated by the slashes is the name of a folder that it lives inside of. And for some of you this might seem like well duh. But for a lot of people you probably have never even heard that that computers store files in this way. And this is extremely important because when we start to write our own programs those programs are going to be stored in files. When we start to build out web servers those are going to be computer programs that serve files to other computer programs running on other computers. So ev everything everything is a file. It's important that you have a good grasp on how these things are stored on your computer. I'll show you the same thing on Mac OS. So, we're at the root. We can go into the users folder. In this case, I have a user called CJ. We can go in there. We can see there are some other folders in here. We stored that file in a folder called documents. So, it lives inside of there. Wonderful. If you want to see that same path that shows exactly how we got here in Finder, you can go to view and then say show pathbar. And this will show you how we got here. So what folder was inside of what folder was inside of what folder to get to this particular file. And of course I'll show you over here on Ubuntu Linux as well. So this is going to be in a folder called home. And then there's a folder for that user CJ. And then we see all of these folders. And then there's a folder inside of there called documents. And then finally we have that document as well. And here on Ubuntu you can click in here to see that full path to how we got to that file. Okay. So computers are made up of folders starting at the root and then every folder can have other folders inside of it or have files inside of it. But any given folder could have more folders or more files inside of it. But at the end of the day, everything comes down to files. And this is where we store information. Now, what I've showed you so far is just plain text. This is stuff that you could type out on your keyboard and represent in the file itself. It is a text file. And there are lots of different types of files. If we take a look at this Wikipedia article on file name extensions, you can see that .txt is the extension you'll use when we just want to represent text inside of a file. But there are other types of extensions like MP3 for music orexe for executable or computer program or as we'll see with the computer programs that we write, we might have a.js for a JavaScript file or or a HTML for an HTML file or a CSS for a CSS file. So absolutely everything is a file. I can't get tired of saying it because you need to internalize this. Everything is a file. Now, another thing that modern operating systems try to do is hide from you that extension. But if we want to actually see what is that extension on there, we do see this type column, but that doesn't tell us what the extension is. If we want to see it on Windows, we can go into options here and then click on view. And then we want to uncheck hide extensions for known file types. Again, they try to hide this information from you. They're trying to make it easier to use, but I prefer to see it and know what's going on here. So, if I do that, you can see it has that extension txt. Now, on Mac OS, they also are hidden. So, we can go into Finder, settings, advanced, and click on show all file name extensions. And there you go. We can see that this one actually isn't a TXT file. It's an RTF file or a rich text format file. And the thing about rich text format files is instead of just plain old text, they can also store more information like the font or the size of the font or whether or not it's bold. And so all of that extra information about the file is stored in there as well in this RTF or rich text format. Um, I digress. You didn't really need to know that. But with a txt file, it doesn't have that kind of information inside of there. So that's how we see file extensions there. And then you already saw on Ubuntu they don't hide the file extensions from us by default. So we can see that this is a txt file. So everything's a file. They live inside folders and every file has a particular extension or is of a particular type. This is fundamental knowledge that you should internalize. You should memorize and carry with you as you go about writing computer programs or asking AI to write computer programs for you because at the end of the day when it's writing these programs it is creating files. So all the files we've looked at so far are just text inside of a file. They're just words in that file. But as you may have realized as you're using computers, we can store much more interesting things like images. So this is a photo of 41 Cooper Square I took while I was in uh New York City. Um but as you can see, I can put this inside of a folder as well. And that's more than just text. It's it's information, right? It's an image, right? And so in the physical world, I had to literally print this out onto photo paper so I can handle it and put it inside this folder. But we can store images on computers as well. So let's take a look at how I stored that image across all three of these operating systems. If we take a look at Windows, I stored it in the pictures folder. So if I want to get there, first we're going to go up to the folder that is my name. So I can click on it. And then you can see all the folders here. I want to go go into the folder called pictures. That's where I actually stored this thing. And there it is, 41 Cooper Square. And you can see it has a different file extension, right? It's not txt, it is. JPG. So, this is the file extension we use to store JPEG images. And uh if I double click on it, that's going to open with the default image viewing program. And there we go. I have that image stored on my computer in that particular folder. I did the same thing on Mac OS. If I want to get to it, I can click on the CJ folder, which goes up one, and then go into the pictures folder. And there it is. 41 Cooper Square.jpeg. So JPEG, JPEG or JPG, they actually are the same thing. It's just two different ways to write it. Uh but if I double click on this, this is going to open up with the preview program, which is the default program for viewing that image on a Mac. And of course, over here on Ubuntu, we can do the same thing. I know it might be it might be getting old, but I just want to drive home how all of these operating systems, even though they're different, are doing very similar things. So we can go up then into that pictures directory, and there it is, 41 Cooper Square.jpg, JPG and then this opens with a program called image viewer but we can see it as well. Now the major difference between that text file we created so if we go back up here and then into documents the major difference in how this information is stored is that instead of storing just text the image file is storing what's known as binary information. And so there is a format that describes for any given operating system when they come across a file that ends with JPG it's going to try to read it in a particular way. And so there is data inside of this file that basically represents every single pixel and what color that pixel should be and how bright it should be and how many pixels there are and how wide the image is. All of that information is stored as binary inside of this file. That says lowlevel we're going to get. We're not going to dive into like what makes up the JPEG format. But you can think of any given file that isn't a text file as a binary format. So we have image files. They're also video files. Sompp4 or webp are common extensions for video files. There's also audio files. So there's wav or wave ormpp3 or aiffff. All of those are files that store audio information inside of them. And any other file extension you come across. If it's not a text format, it's going to have some sort of particular binary format so that computers know how to read and display the information stored inside of that file. Now, with everything we know about files, file extensions, file formats, we have enough to write a computer program. So, let's do it. Now, I'm going to show you across all three operating systems so you can see how similar and different these things are. But first, we're going to dive into the CJ folder, and I'm actually going to put this in documents. So, here on Windows, I am going to create a new text file, and I'm going to call this say hello. say-h hello and I'm going to change the file extension. Instead of txt, I'm going to call it.bat or batch file. It's going to warn me, are you sure you want to do this? Yeah, I'm sure. And now you can see it's updated the type here. Now, I'm not going to double click on it because I want to actually put some instructions inside of it. And you don't have to memorize or understand anything I'm about to show you. All I want to show you is that we can now put instructions inside of files and then computers will operate on those instructions. So in this batch file, if I put the instruction echo and then I put hello world here, this is a computer program specifically for Windows, specifically in a batch file that is going to output the text hello world. And echo is a particular command for this particular batch programming language. So I'll save this file. And now that it's saved, when I double click on it, the computer is going to run those instructions. And so even though this is called BAT, it's still a text format. So there's nothing really special about this file except for the fact that when Windows sees it, it knows that it can actually try to run the instructions inside of it. When Windows sees a text file, it just wants to display that information. But I have actually written instructions for the computer to perform. So if I double click on this, you'll see that it opens up a window and then closes again. But if I want to see the actual output, it's going to get a little trickier. Now, I'm going to move fast here because you don't need to memorize any of this. I really just want to show you what's happening. So first of all, we've now introduced a terminal. And so this is another computer program and this is a way of interacting with our computer but with text commands. So here you can see that it has that file path that I showed you earlier. So it says that we're inside of the CJ folder. If I want to go into that documents folder, there's a command I can run called dur that shows me all of those folders. And let's say I want to go into the documents folder just like we were doing by double clicking here. I can say cd or change directory and then type the name of documents. And now if I do dur we can see there are two files in there. There's a message file and a bat file. Now again you don't have to memorize any of this. All I want to show you is that there are other ways of interacting with this information that we've created on the computer. So here let's say I actually want to run this BAT file. I don't want it to just open and close immediately. I want to see what that output is. To run it I'll just give it the file name. So I'll just do dot slash say hello. Hit enter. And would you look at that? It outputs hello world. And I can change my program. Right. So I can go in here. I can edit it. I'll say hello world again. Save that file. And if I run it again, now it has the updated message. So this is our very first super basic computer program. It's just outputting some text. And you can see there are different ways of interacting with a computer. There's this visual way where we can click or there's this more manual way where we can type the names of the things that we want to run and the names of the folders that we want to go into. So that's how things work on Windows. Let's take a look at this on a Mac. So, here on a Mac, it's going to get a little bit trickier, but I'm going to go back up to the CJ directory into the documents folder. This is where I'm actually going to put our computer program. And I am going to use text edit to create it. Now, here in text edit, by default, it creates these RTF documents or rich text documents. I need this to be plain text. I don't want it to have any other information. So, in text edit, I can say make plain text. And now, I can type my command. So, I'm going to say echo hello world from a Mac. You can see that it's capitalizing stuff by default. I don't want that echo command to be capitalized. Okay, so now I want to save this thing. I'm going to put it in the documents folder. And now you can see that it's defaulting to that. TXT extension, but here I'm going to call it say hello. And instead of txt, I'm going to use orshell. And so this is how we can create super basic computer programs on a Mac. And to run this, there is also a terminal application. So if I go to my Launchpad here in the other folder, there's this thing called terminal. And this is very similar to that application we saw on Windows. But this lets us navigate around our computer using commands. And so if I do pwd, we can see where we are. That's print working directory. And I want to go into that documents folder. And then from there on a Mac, if I do ls, that means list the files. And I can see first of all, I need to give it access. But we can see there are those two files, message.rtf and sayh hello....................sh. Now if I want to run say hello.sh. things are going to get a little bit trickier on a Mac because it says permission denied. Now again, you don't need to memorize any of these commands and uh these types of things you could have an entire course on. But one thing I need to do particularly for a Mac is make this file executable because I want to execute this file to run the instructions inside of it. So I'm going to run this chimad command to add the executable permission to that file. Again, don't worry about this. You don't need to memorize this. But now that it's executable, when I run it, it's going to actually run that echo command. So this is our very first computer program. It is just a text file, but that text file has a different extension, not .txt, which lets the computer know that, hey, I can actually run the commands inside of that file. Now, here on Ubuntu, it's almost exactly the same as a Mac. So I can go back up to my documents folder. I can open my text edit program. In this case, I want to create a new document. We're going to say echo hello from Ubuntu. We'll save it. I'm going to call this say hello.sh. It puts it there. If I actually want to run that file, I'm going to need to find the terminal here in Ubuntu. And on Ubuntu, it's called terminal as well. Now, all of the commands that you run here in Ubuntu are exactly the same as on a Mac, which is actually why I prefer to use a Mac because it's very similar to the operating system that's running on a lot of servers, which we'll talk about later. But again, I can do print working directory. I'm in here. I want to go into uh documents. Great. We have that say hello file. It actually works exactly the same way. If I were to try and run it, it would say permission denied because I need to add that executable permission. Again, don't need to worry about this. I am just trying to show you an example of our first basic computer program. And now that I've added the executable permission, boom, I can run my program and uh it runs those instructions. So, all of this to really just show you everything's a file. There are certain types of files. Text files are kind of the most basic type. There are binary file types that can store lots of other types of information. And there are other types of text files that can actually have instructions for the computer to run. And these text files with instructions for the computer to run are computer programs. We can basically write out all the instructions of what we want the computer to do and it will perform those instructions one by one. And this this is the amazing thing we call computer programming. We're basically writing instructions for the computer to perform. And when we give it those files with the instructions, it's going to perform those instructions in that same way every single time. Now earlier I mentioned that the worldwide web is made up of various protocols and protocols are essentially just established ways to communicate. If everyone follows the same protocol, if every computer follows the same protocol or every program follows the same protocol, they're going to be able to exchange information in a meaningful way. And the first protocol that we use on a daily basis is HTTP or the hypertext transfer protocol. And this is a protocol for how to exchange files or documents over the worldwide web. Now HTTP is a request response protocol in the client server model. This one sentence describes almost everything that's happening in the world over the web right now. Like what's happening with you watching this video that's it's the request response protocol. It's happening with clients and servers. So this is one of the most important concepts that will allow you to kind of understand how all of these things are pieced together and and communicating. Now first let's get into request response also known as request reply. The idea is that one computer can request some information from some other computer and that computer if it's listening for that request can potentially send a response to that request. And so one request might be please give me your message.txt file. And if the other computer is listening and it has a message.txt file, it might respond with the contents of that file. And so this is request response. And everything we do on the worldwide web is happening via request response. Every time you visit a website, you're requesting that website from a server. That server responds with the contents of that website and then it gets loaded into your web browser, which we'll talk about in a second, but it's all request response. And it has to do with this client server model. So when one computer requests information from another computer, this is the client server model. The computer making the request is the client and the computer responding is the server. And any given computer can actually perform either of these roles. It it doesn't just have to be a client or just have to be a server. And so as we're navigating across the web, visiting websites, watching videos, downloading pictures of cats, all of this is happening with requests and responses, all of this is happening with clients and servers. Now to see this in action, I'm going to turn my Ubuntu computer into a server that I can then make requests to from my Windows computer. So for this, I'm going to use a command called nc or netcat. And again, you don't have to run any of these commands. You have you don't have to know what this means, but this is basically a Linux program that's going to be listening for incoming requests on a given port. In this case, port 8000. You could think of ports as doors or windows into a computer. So essentially I have opened up a door on port 8000 of this Ubuntu computer and any other computer can make a request to this server on that given port and they can talk to each other. This server can then send responses. Now if I want to talk to this computer I need to know its address and this is similar to like a home address but this gets into TCP IP or networking and what I'm going to do here on Ubuntu is I'm going to go into my settings and this is going to tell me what the IP address of this Ubuntu computer is. So, it is 1 192.168.64.4. Now, this is a local IP address. I don't have to worry about you hacking me because there's no way for you to get to this computer over the internet. It's just local. But again, I digress. You don't need to worry about that. Basically, I have its address. I have its port. Now, I can make a request to this server from some other computer. So, here on Windows, I have Microsoft Edge open. This is a web browser. We're going to talk more about what web browsers are in a second, but web browsers are clients and they can make requests to servers. So, what I'm going to do is I'm going to make a request to http col/192.168.64.4 col 8000. And so, this will make an HTTP request to that server at that address on port 8000. So, I'm going to hit enter. And now, this client is waiting. It's waiting for a response. So if we head back over to Abuntu, we can see it received that request and that web browser is speaking the HTTP protocol. You can see that there are lines of text, but this is the protocol. It basically says when you're making a request, you should declare what kind of request you're making. In this case, it's a get request. Request what resource you want. In this case, slash. What version of the protocol are you using? And then these next bits of information are known as headers. And they contain information that my server can use to respond. And so this these headers are basically extremely generic. They're saying this request is coming from Microsoft Edge and we accept all of these different types of data. You can send me anything you want, but it's waiting. And so if I go back over to Windows, it's still like I'm waiting for that server. That server needs to respond at some point. So if we want to respond, we can type out our response using the HTTP protocol. So here I'm going to say we are confirming yes this is HTTP protocol version 1.1 and you are receiving a successful response from this server. So there's different status codes. 200 is the success status code and then we need our status text. I'm just going to say okay. So this is this is a good response. Here we go. So I just sent that information back to the client that requested it. And now I can include headers of my own. And so I'm going to tell it that the content type of the data I'm about to send you is text/html. And that essentially lets the client know that they're going to be able to show this information. So I'm going to hit enter again. I just sent that information back. Now the fun part. What is the actual body of the request or what is the data that I'm sending back? First of all, I'm going to send back hello world from Ubuntu. And the moment I hit enter, I have just sent that data back. And because on the other side the client already saw, okay, this is going to be a successful response. They're going to be sending me text. If we go back over to Windows, would you look at that? It got the message, hello world from Ubuntu. So, it's still waiting, right? The part of the protocol is to wait as you get information and it's not going to stop waiting until the server has said, "Okay, I'm done. That's the full response." And from here, we can keep sending information. So, I'm going to tell it that I want it to show this on a new line. So, I'm going to do slashin. Actually, I'm going to do a couple of new lines. So, this should be some empty spaces. And then I'll just say, "Wow, look at this." And that's going to send all of that across the wire as well. And it didn't interpret those new lines. I think I need to do like a slash R. It doesn't matter. But basically, my server is responding. So in this scenario, this Microsoft Edge web browser running on Windows is a client in the client server model. This client is speaking the HTTP protocol and this server is responding with that HTTP protocol. So Ubuntu in this case is the server in the client server model and it is speaking that same protocol. So the Microsoft Edge client can actually do something with the information it's receiving back. So we could go back and forth like this all day at the end of the day to let the client know that okay I've sent you all of the data that you're going to receive for Ubuntu. I'm actually just going to kill the program. But once the program is killed that has closed the connection and that's enough information for the client to say okay I received everything. I am now done. So if we go back over to Windows you'll see there's no more spinning and it has basically received that information from the server. And so this is the most basic HTTP server you could ever have. And it essentially has to respond like this to every single client that comes in. And this would not be ideal, right? If we were literally sitting at our computers uh on the server responding manually to every single request that comes to us, this is where computer programs come in. So we can essentially write a computer program that is always listening for incoming requests and then can respond to those incoming requests with files, with data, ultimately with websites and information and all of the things that we use and exchange across the web. And one of the main things I really want to drive home here is any computer can be a client, any computer can be a server. And there's nothing special about the servers that are serving up the websites that you're visiting or are serving up YouTube for the videos that you're watching. The only special thing about them is that they're really big and really beefy. So, they have lots and lots of memory and big hard drives and a really fast internet connection so that when millions and millions of people are making those requests, they can efficiently respond. And it gets even more complex because they actually have thousands and thousands of computers that all sit behind some other computer. And that computer basically says, "Okay, I'm getting millions of requests. Those requests go to this computer and that those requests go to this computer." And that gets into system design and scaling. None of which we need to worry about. But at the end of the day, when that request finally reaches the server, it's just a computer. Just like your phone is a computer, your watch, your TV, everything's just computers. And they're all requesting and responsing all the time. And that's what basically makes up the world which is run by computers. So the worldwide web works off of the HTTP protocol and other things but for the most part HTTP. And there are web servers. So a minute ago I showed you a super basic server where I was literally the one responding to the client that was making the request. And the other piece of this puzzle are web browsers, which we've already hinted at and which I've been using this whole time, but I want to dive a bit deeper into what those actually are. So, a web browser is a computer program. It's a computer program that's been purpose-built for speaking the HTTP protocol and navigating across the worldwide web. It is a client application. It makes requests to web servers. So, it is the client and the client server model. And there are a lot of different web browsers. Now, statistically speaking, you're probably most familiar with Google Chrome because it has a 66% market share. If you're on a Mac, you might be using something like Safari. If you're on Windows, you might be using Microsoft Edge. You could be using Firefox across any one of these operating systems. It actually comes installed by default on Ubuntu. And then mobile devices either run Google Chrome if you're on Android or Safari if you're on iOS or some Samsung Android devices will use the Samsung Internet web browser. And then Opera is another thirdparty web browser that you could just install yourself directly. So all of these things at the end of the day are there to perform the same function. They are client applications that speak the HTTP protocol and can make requests to servers. So for instance, if I'm here on Windows, I can launch Microsoft Edge and let's say I want to go to Wikipedia. I'm going to go to wikipedia.org. I type that address in. I hit enter. This computer made a request to the server at wikipedia.org. That server then responded with the contents of this web page and now it's displaying that web page to me. And so this is the same process that I just showed manually with that netcat command except there's an actual server that's responding to every single request that comes to it. So Microsoft Edge is one web browser. Let's take a look on Mac OS. By default, they have the Safari web browser. And again, I can launch it and we're going to go to wikipedia.org. Safari made the request to that server and then rendered it out. Here you can see that it's displayed slightly differently because I have a dark mode set here on this Mac OS instance but uh the same same process happened even though I'm on a separate operating system different computer I can do the same thing and access the same web and of course here on Ubuntu we can do the same thing in this case I'm going to use Firefox and I can go to the same website wikipedia.org or and it renders out and again I have dark mode set here on on Ubuntu but the fact that no matter which operating system I'm on whether it's Mac, Windows or Linux or Android or iOS all of these have browser applications all of those browser applications speak the same protocol which means we can all navigate to the same websites regardless of what kind of indevice or client we are using. Now I showed you Firefox, Safari and Microsoft Edge. They all behave in a similar way. There's a place to put the address in. There's a place where it's going to show you the actual web page. The one that I didn't show you is Google Chrome. And Google Chrome can be installed on pretty much any operating system. So can Firefox. I think maybe you can even do Edge these days. But Chrome works in exactly the same way. We can go to wikipedia.org. It renders it out. Now, you might be wondering why do we have so many different programs, competition, opinions. Uh there's a long history of why all of these exist. And if you want to learn more, you can look into the browser wars. And so this was an era of time where companies were competing for market share to get people to use their specific web browser. Uh but like I mentioned these days Google Chrome has kind of won. At the same time there are other ones that are based on top of Google Chrome. So technically Edge under the hood uses the same stuff that Google Chrome uses. Similarly if you use the Brave web browser that's built on on top of Google Chrome. So Google Chrome not only has a large market share it also is the basis that other browsers use. Safari and Firefox are all are their own separate things. They they don't use Google Chrome itself. All of this to say they're all web browsers. They might look slightly different. They might behave slightly different, but at the end of the day, they speak the HTTP protocol. They allow you to visit websites. And essentially, no matter which device you're on or which browser you're using, websites, for the most part, end up looking the same. And that's because they all follow these same protocols. And the main thing that I want you to walk away with is web browsers are clients. They're a client application in the client server model that makes requests to servers and servers respond with websites. Now, we're going to get into what actually makes up a website and from there we can start to build our own websites once we know what what makes them and and how to build them. But at the end of the day, our websites are running inside of web browsers. So, we should be aware of that fact. Now, I mentioned the browser wars. There is this idea that even though they're all speaking the same protocols and they're built upon the same standards, not all of them implement it in exactly the same way. like for the most part and for the things that are most common, yes, it doesn't actually matter which browser you use, but when you start getting into the the nitty-gritty, the the intricacies of certain features, you might find things that will work in Google Chrome, that won't work in Firefox. And honestly, that is one of the bins of every web developer's experience building websites is you might come across things that don't work exactly like you expected them to across web browsers. But for the most part these days, it actually is a lot better than it than it used to be. It used to be really bad. These days, it's pretty decent. If you stick to most of the stuff that is standard, you're going to be able to build websites that work across any web browser, any operating system, any type of computer that can visit these websites that you build. Now, just like with operating systems, I think you should develop a preference over which one you like to use the most and which one you like to develop with. Now, if you're building a product for end users, you absolutely need to use multiple because you need to make sure that the thing that you're building, the website you're building works across different web browsers and different operating systems. And and that's one aspect of being a web developer or or a programmer that builds web applications is making sure that it works across various devices and web browsers. Now, a lot of times people focus in on one and because Chrome has the largest market share, you might build a website and say, "Okay, I'm only worried about Chrome." But if someone visits that on iOS, maybe they don't have Chrome installed and maybe you're doing something that isn't supported in Safari, you might actually lose a user. You might lose business. So part of being a web developer is making sure that your sites do work across all of these browsers. But on the day-to-day, I would develop a preference and pick one. Personally, I use Firefox. That's every website you've seen me visit so far. I've been using Firefox to do that. And so I like Firefox for various reasons, but a lot of developers do tend to use Chrome these days. Now, when you're using a web browser and visiting various websites, you are using a URL. And you've probably already heard that term, like someone says like, "Share that URL with me." And we've been using URLs, but let's actually break down what those are. And also, URL stands for uniform resource locator. And essentially, it's a format that allows us to locate anything on the worldwide web. And it's broken down into a few different parts. First, you have the scheme. And this is what's the protocol. For the URLs you've seen in this video, the scheme has been HTTP. But in the past, you might have also seen HTTPS or FTP or RTMP. These are a bunch of other protocols, but all these can be used when making up a URL. So, you have the scheme HTTP, then a colon. There's always going to be a colon, followed by a slash followed by the authority or the server or in the examples we've seen, the IP address. So where is the thing that we're trying to visit? In the initial examples, I showed you a local IP address. In the examples with Wikipedia, the authority is Wikipedia.org. And we talked about it earlier, but under the hood, there's this whole mechanism for turning that name, Wikipedia.org, into an actual IP address. That's the DNS, domain name system that's happening under the hood. And we're not going to cover that in this video. Like I mentioned, I've talked about it in past videos, but at the end of the day, that is a unique location of where that computer exists. So behind that name wikipedia.org is an actual IP address that's accessible on the public internet but that is the authority. From there we have the path or and here is where it comes all together. What file are you requesting on that given server. So when we go to httpsikipedia.org slash we are requesting the root document. We didn't specify anything. And actually you can even leave off that slash because the web browser is going to do it automatically. It's basically going to say, "Hey, give me the root document." But that's the path. As we click around, this is part of the hypermedia aspect of the web. You'll see that that part after wikipedia.org is changing. And this essentially is requesting a specific file on the server. Now, there's more to it than that. It's not always just an individual file, but that's the way you can think about this. I am literally asking for main page. Wikipedia.org, the server that's running, finds that page and then sends it back to me. and then it displays here in my web browser. And so earlier when I was showing you files on our computer, it's it's doing a very similar thing except there's a computer program that's actually sending those files over the network. So when you look at a URL, you're going to see that path and that is think of it like what file or what page are we requesting from that given authority or from that given server at that domain or at that IP address. From there, you can have some other aspects of the URL. You have the query which sometimes can start to filter results or add more information onto the request. And then you also have the fragment. The fragment is actually used a ton on Wikipedia itself. So if I look here in the table of contents and let's say I click on one of them, you'll notice the URL changes to have the hash and then the fragment after it. And so fragments are actually used to link to a specific section inside of a web page. So if I click on this, you'll see the fragment changes and then it scrolls down to that section of the page. So fragment is for a specific section of the page. Path is a specific file or the page itself. Authority is where does that server live? And then scheme is what protocol are we talking to get access to that thing. So as we build out websites and as we navigate around the web, these things actually mean something. And when you share a URL with someone, you're essentially giving them everything their computer needs to know to access that specific web page or that specific document or to talk to that specific server. Now, another example of this I want to show you is on Amazon. Now, not everyone uses Amazon. Some some people boycott it, but it's actually a really good example of all these different parts of the URL. So, let's say I'm looking to buy a gaming computer. I'm going to search for gaming computer. Hit enter. And then I'm navigated away to some other page. But notice what's happening in the URL bar up here, right? We see that the path is slash. We see the authority or the domain is www.amazon.com. We see a bunch of stuff after the question mark. And so, this is a a fairly complex example of this query that has more information about this given request. And so this query says, "Oh, we're searching for a gaming computer." And then there's a few other things in here that I don't know what they mean directly, but these are typically bits of information that are used to track this URL across the web. So if you were to share this URL with someone, Amazon would know potentially based on this CRI ID right here that you were the user that originally created that URL. And then when somebody else goes to that URL on Amazon server, they can basically look at that piece of information and be like, "Oh, CJ was the one that made the link, but then Bob clicked the link." And so it links those two people together. And then if we click on a a given product, we can see, let's break it down, that the path changes. And so this path is potentially a different file on Amazon servers that represents this given page for this given computer. And then again, there's a big old query string with a bunch of information inside of here. And really, a lot of this is tracking information. A lot of it is when you share this URL with someone else, they know where it originated. And that's how they start to suggest products to you. So like if your friend shared a link with you, and all of a sudden you're seeing advertisements for stuff that your friend is interested in, that's why because Amazon is tracking you through through those query parameters. Um, now this this gets into something completely different. But one thing I want to show you is especially with Amazon. This is just like a little fun fact, but let's say I go to this page for this particular computer. I can actually remove everything after the question mark and the page will still load. So if I get rid of all this and then try to go here, this actually behaves weird, but if I open up a private tab, so if they've never seen me before and I go to this URL, it still loads. So ultimately, all the information that your computer needed to load this web page was the domain and then the path itself. All the extra query parameters are specific to what Amazon is doing. Not every website works this way. But with this newfound knowledge, I want you to be more aware when you're navigating around the web and when you're sharing links with people and play around with it. Try to remove some of the query parameters. See if it still works even if those query parameters aren't there. Um, basically just experiment and keep an eye on that URL bar because that means something. And the more you understand it, the better you're going to be able to leverage this when you're building your own websites. Now we get into the fun stuff, which is actually building out our own websites. And in order to do this, we need to be able to create custom files that make up any given website that we're attempting to create. And I first want to show you that there are some websites that let you build websites. It's very meta, I know, but I I want you to think about this because we're going to be creating websites outside of the web browser. We're going to use custom computer programs, which I'll talk about in a second, but you need to think about this when you're navigating around the web. So, one of the most common ones you'll see is code pin. And this allows you to build a website by typing in your HTML code, your CSS code, and your JavaScript code in these three tabs. And then it'll render out the website below. But this is a website running inside of a web browser, right? We are not necessarily in direct control of where these files are or where they exist. And that's the thing I want you to start thinking about. And another example of this is on Free Code Camp. So if you've ever used Free Code Camp to learn how to code, they do this very similar thing. So Free Code Camp is a website, but they give you a place where you can start to type out your files and then they show you what those files would look like when they're rendered out. But again, this is happening inside the web browser. And of course, if you've used any Vibe coding tools, they do this exact same thing. So here on Lovable, I gave it a prompt to generate a web page for me that describes how computers work and um how programming works. So, it spit out this web page, but if you've ever looked, there's this tab up here called code. And when you click on that, that's going to show you all of the files that it created that make up this website. And there are a lot of them for this particular site that it created. But this is why we talked about files earlier because as you build out websites yourself or try to modify what these vibe coding tools are doing, you're going to be modifying these individual files. And you can see that all of these files have various extensions like TSX or CSS or SVG or TXT. We know that one. But each of these extensions means it's going to have a different kind of code inside of it. And so if you've never clicked this tab, give it a try and and kind of just peruse the files that it's generating. And of courseh, this is going to be another one of the files that we create manually oursel. And we'll talk a little bit about what actually goes into them. But this is one of the other reasons why these vibe coding tools aren't amazing is at a certain point you might want to modify these files directly. And as far as I know on lovable you can't do that. Like there's no way for me to click in here and change the code myself. Um and there might be like you have to pay for it in order to be able to edit the code. That's one aspect of it. But at the same time if you remember we're inside of a web browser. Like we are on a web page that is let us letting us edit these files which we don't have direct access to. Now, we could of course click download and then we could edit those locally, which is what I'm going to show you in a second. But this is another reason why I want to break out of the web browser is they're they're definitely limiting us. Now, I did the same thing on Replet, which is another one of these vibe coding tools. I gave it the same prompt. Give me a website that tells you about programming and computers, and it it created this website. Fine. But where are the files? What actually makes up this website? If you click this button, it's going to show you all of the files that it created. And again, we're going to see some stuff. We're going to see some.ts, ts some.json JSON, which is one we'll talk about as well. And we see folders, right? We talked about folders contain multiple files. So, if I click into one of these, we can see all of the files that exist inside of there. And if I go into them, then I can actually start to edit them. And I believe uh Replet does let you edit the files directly. But taking a step back, this is inside the web browser. Like they're basically they've locked us in. We need to break out. We need to be able to we want to be in full control of these files and edit them to our heart's content and not be limited to a certain number of edits or a certain number of tokens or whatever else. So to do that, we're going to use a purpose-built computer program called an integrated development environment. And so this is a computer program that runs directly on your computer. It doesn't run inside of a web browser that allows you to edit files and basically create all of the computer code that is going to make up your website. Now, there are a lot of different IDEs and typically depending on what programming language you're writing, you might choose a different one, but there is one from Microsoft called Visual Studio Code, and it can be installed on any operating system. So, you can install it on Windows or Mac or Linux, and it allows you to edit code. This is one of the most common IDEs. Some people might say that it's not an IDE. It's more of a text editor. That's fine. At the end of the day, it allows us to write code and we can install it directly on our computers. So, this is the program that I'm going to be using and you can go to their website code.vvisualstudio.com and download that program for whatever operating system you're using, whether it's Windows, Mac or Linux. And once you have the program, then we can start editing and creating files directly on our computer and start building out websites that we are completely in control of all of the code. Now, I'll also mention that you don't necessarily have to use something like VS Code. There are things like Vim, which is a terminal-based text editor, and you might have come across certain people that use Vim to edit all of their files. This gets even more complex because you have to also know a lot about the terminal. I touched briefly on what a terminal is earlier, but that's a whole other beast that we can potentially get into. Uh, but Vim is an example of an editor that runs inside of your terminal and then people use that to create all of their files. And another one that's really common on Linux systems is known as Nano. It's similar to Vim but a little bit easier to use. But this also works directly in the terminal. Now at the end of the day, you could also just use a text editor. So I showed Notepad on Windows. I showed text edit and the text editor on Ubuntu and on Mac OS. These programs let you edit text files directly. But when you start writing computer code, you want to get some help. And VS Code has a lot of things built in that'll give you a lot of stuff that makes it much nicer to write your code inside of. So you're going to get things called syntax highlighting. You'll notice that different words are different colors and that helps us when we're writing the code to identify what's what instead of everything just being the same color. Also, depending on which language you're writing, it will give you hints as to what exists or what you could write. And so, that makes your your life a little bit easier as well. So, from here, you can go install VS Code and I'm going to show you how we can actually write these files and and build out our own website. Now, if you aren't in control of the computer that you're on, like let's say it's a computer in the library, or maybe it's your parents computer and they don't want you to install a program, I would say you can use code pen. Code pen is going to let you uh write the files that we're going about to talk about. And we're going to talk about what these things are, HTML, CSS, and JavaScript. And so, this site also works on mobile. So, if you don't have access to a laptop or desktop where you can install VS Code, you could use something like CodePen. And that'll work for basic websites. When we start creating our own servers, that gets a little bit trickier. You're going to need some kind of editor to be able to write that code and some kind of computer to run it on. It's gonna be a lot harder to do if you're if you're still on mobile. So, from here, install VS Code. And in the next section, we'll create our first website, which is made up of various files. Now, in the next portion of this video, I'm going to show you some code. And my intention is not for you to follow along directly. You can try to follow along, but ultimately my goal is for you to see what these things are and how they exist to kind of build out this mental model of how websites are working as as you navigate the web and also as you start to build out your own websites. For each one of the things I'm going to show you, you could have an entire course on learning that particular language or that particular technique. I'm just showing you a whirlwind tour of all of this stuff put together so you can start to build up a mental model of what code runs where or what specific types of code are for and and really how all of this stuff on the worldwide web fits together. Okay, so I have VS Code open here on my Mac. It should look similar even if you're using Windows or Ubuntu. And if you click on this icon here, it'll show you that you have not opened a folder. So inside of VS Code, we can essentially navigate to any folder on our computer and start editing and creating files in that given folder. So let's create one. I'm going to click open folder. I'm going to head into my documents folder and then create a new folder inside of there. Essentially, every time we work on a new project or a new website, it makes sense to put all of those files for that website in its own folder. So I'm going to call this my first website. So that creates a folder here. And then I'm going to open this folder in VS Code. Now in this case, I am the one creating the folder. So I'm going to say yes, I trust the authors. And now we can start building out our website. The first thing we'll do is create an HTML file. So if I right click over here, say new file, I'm going to create a file called index.html. And this is where we'll define the structure of our website. So I'm just going to create a basic landing page that has a simple message on it. Uh, and for now, I'm gonna close out this chat because we don't we don't need AI here. And this is not going to be a full tutorial on HTML. I'm just going to show you the basics and it's up to you to go off and and learn more. And so when we're writing out HTML, we can create tags. And so this starts with a less than and then the name of the tag. Our first tag is HTML. And then we do a closing greater than. And after that, you see the closing tag that also has the slash inside of it. And so this is an HTML tag. And we can put all of our other tags inside of it. We'll also have a head tag. And inside of there, I'm going to define a title tag. Here, I'll put the title of my website. So, I'm just going to call this my first website. And this particular tag tells the web browser when it's loading this web page what should be displayed as the title of the page, like in the in the tab. Now, after this, I'll create my body. This is going to be the main section of the page. And inside of here, I'm going to add an H1, which is a header. It's going to say hello world. And then below that, I'm going to add a P tag that says this is my first website. Okay. Each one of these things with the opening and the closing is known as a tag. There's lots of different kinds of tags. As you write out your HTML documents, it's going to start to look like this. And you'll learn about a lot more tags. But now that we have this page, we can try loading it in a web browser. Now, there's a few different ways to do this. You could just rightclick this file and then say reveal in Finder. And if you doubleclick that file, Mac OS will open this in your default web browser. Right now, I have Google Chrome set as my default web browser on Mac OS. whatever operating system you're using, whether it's Ubuntu or Windows, it'll open in your default web browser as well. But you can see the page actually loads. And if we look in the URL bar here, we have the path to the file. And this isn't loading it from a server. As you can see, it's just the file path. So, it's the direct path to where that file exists on my computer. And web browsers like Google Chrome or Safari or Firefox, they're actually able to load local files like this. Now, we can see the title is rendered out here. my first website. We can see that header that H1 renders out a little bit larger and then we can see the paragraph tag gets rendered out there. So essentially we can define our website using these HTML tags and then when it gets loaded into a web browser the browser has what's known as a rendering engine that has various rules for whenever it encounters certain tags how those should be rendered on the page itself. Now you can see where everything we've talked about so far has kind of led up to this moment. Right? We are creating files. In this case, it is just a text file, but it's a text file that has HTML text inside of it. And then that file is then loaded by a web browser to render out the page. Now, if we want to create websites that can be loaded on other computers, we actually need some kind of server because if you remember the client server model, we have the web browser here, which is the client, and it makes requests to servers. So, instead of just loading this file directly, we could have a server that actually serves up these files when they are requested. Now, to do this, we're going to install an extension inside of VS Code. If you click this icon here, this takes you to extensions, and you should search for live preview. And there is this extension here from Microsoft. It has the blue check mark, and it has 11.1 million downloads. When you're installing extensions in VS Code, you want to be very particular about what you install and make sure you install things that are trusted because these extensions can essentially do whatever they want on your computer once they're installed. So, I know that this one is from Microsoft. I can trust it. It has lots of downloads. And I'm going to install it. And this is going to give me a static file server so I can test out how my website will work when it's actually being loaded from a static file server. So, with that installed now, if we head back over here, we can press command shiftp, search for live preview, and there is an option here called start server. I'll do this, and you'll notice it opens up a web browser inside of VS Code. Now, you can use this to preview your site, but I like to use Google Chrome directly. So, I'm actually going to close this. I copied that URL. And now, if I go to that URL, Google Chrome is actually going to load my website here. And remember, we talked about earlier this query string stuff for this particular instance. We can get rid of all of that because the thing that we want is the index.html. And then we can see that this is now loading it via that static file server. Now, here inside of VS Code, you should see the status down at the bottom that tells us it's running on a particular port. And if you ever want to stop it, you can click on stop. But this is a static file server. Essentially, it's a server that's running on this computer and listening for requests on port 3000. Now, earlier when I created the server that was running in the command line, I made the request from one computer to another. So, I had to put in its local IP address. If you remember, it's that 192.168 thing. because everything I'm doing right now is happening on this machine. You'll notice the IP address is 127.0.0.1. So this is also known as local host. But essentially this computer is making requests against itself. It's not going out to some other computer. It's making a request to itself. So in this particular instance my Google Chrome web browser is the client and the live preview server running inside of VS Code on port is the server. So in Google Chrome, when I go to this URL, it makes that request to the server and that server responds with the contents of this HTML file. Now, if we want to see this in action inside of Google Chrome, we can open up the developer tools. So if we rightclick anywhere on the page and go to inspect, this is going to open up the dev tools. And there are a couple of different tabs. I'm going to move this down to the bottom so we can see all of these tabs because the tab that we want to look at right now is the network tab. This is going to show us every single request that the web browser is making in this request response client server cycle. So if I click this refresh icon here, you'll notice that there are some requests that went out. And if we look at this request for index.html, we can click on it. We can see that it was made to this particular URL. The server responded with 200. Okay. And if we look at response, we can see the actual code that we wrote. Right? This is exactly as we wrote. There's a little bit of extra stuff here. So, this got injected so that it automatically refreshes. We don't have to worry about that. Everything else is code that we wrote, right? It's literally what we typed here. Our web browser made the request and then got that actual source code and then there was a process of of rendering, right? So, it went over every single tag. It saw the title. It updated the title here. It saw that H1, it made it a little bit larger. It saw that paragraph tag. It added some text below. So this gets into the idea of where is the code running because the way that we wrote this is just text, right? We have this text file that lives in this folder. We're then running this server which is basically responding with the files from this folder. And when Google Chrome, the client, makes a request to that server. It is sending it the full contents of that file. Now again, you can see there's some extra requests in here. All of this has to do with the live preview aspect where we can make a change and it automatically updates. So let me show you that if I for instance add an exclamation mark here and save the page. When I go back to Google Chrome, it automatically refreshes for us. Now not all servers behave this way. This is useful for when we're in development. This injected code here will automatically refresh it for us. But we don't have to worry about that. Really the main thing to take away from this is there is a server running that literally just responds with the files that are requested. Now this is HTML. Every website you ever visit in any web browser has HTML that describes the contents of the page. Now, websites aren't just HTML. There is also styles with CSS and then interactivity with JavaScript. Now, if you want to learn more about HTML and see all of the various tags that exist and what you can do with them, head over to developer.mosilla.org. This is known as the Mozilla Developer Network and they have tons of free documentation and learning resources for HTML, CSS, and JavaScript, the languages of the web. So, we just learned the basics of HTML and as you can see, there are lots of other HTML elements that you can use and add to your page. And if you click on the reference here, you can see every possible one that exists, learn more about it, learn how to use it. So, MDN is a really great resource for this. Towards the end of the video, I'll have even more resources, but MDN is the go-to place when you want to learn about HTML, CSS, and JavaScript. Even myself, who's been a developer for many, many years, still goes to this website to learn how to do these things on a daily basis. Okay, so we have HTML. That is the structure of the page. Let's add some styles. And we're going to do this with another file. I'm going to create a file called styles.css. And inside of here, I'm going to define some styles for my page. The way this works is you specify which element you want to style. So in this case, I want to style the body. And I want to set the background color to black and then the color of the text to white. basically making like a dark mode. And then I also want to change the font family. So I'm going to set the font family to Sans serif. Now right now don't worry too much about what I'm writing here because like I said you can look up how all of this works and with lots of practice you'll learn how to do this as well. But essentially this bit of code here will target this element and set all of these style properties on it. So when it renders on the page it will have a black background with white text and a sans sarah font. Now it doesn't happen automatically. I need to actually tell the web browser where to find these styles and that it should load them. So, I'm going to do that right here in the head. And I can add a link element and specify the path to that file. So, I'm going to say styles.css. And so, now when the web browser loads this page, it's going to see that I've linked a file. It's then going to request that file. Our static file server that is running is going to respond with the contents of this file. The browser will then see those styles, apply them to the page, and we should get some nice styles. So, let's check it out. There we go. Those styles have been applied to the page. Now, again, let's open up the dev tools. Let's look at the network tab, and let's click refresh. You'll notice there's that initial request for the index.html. And then in the browser, we'll look at this. It'll add all of the elements to the page. But once it comes across this, it says, "Oh, I need that file." So it actually makes that request to our local file server and pulls in the source code as well. So it pulls that CSS and then applies that CSS to the page. Now if you want to learn more about CSS, check out the docs in the Mosilla developer network. They have a ton of resources on the basics of styling and all the other properties that you can use. And you can do more than just basic colors and text. You can also do things like layout like multiple columns. And you can control borders and sizing and width and height and all this other stuff is possible with CSS. Right now, we're just kind of covering the basics. And the main things that I want to show you is we're building out this website, but it's built out of static files, right? We have the structure, we have the styles, and at the end of the day, when someone visits our website, their web browser is downloading each of those files, and then running some logic on their computer to make the website appear as they see it. Now, the last piece of this puzzle is interactivity. So, let's actually add some JavaScript to the page. I'm going to create a new file. I'm going to call it app.js. And this allows us to make our page interactive. So, what I'm going to do is I'll make it so that if somebody clicks on this paragraph tag, I'm going to pop up a message on the page. Now, I'm going to write some JavaScript code here. You don't have to know the specifics of it. I'm just going to describe what it does and eventually as you learn more about JavaScript, you'll be able to kind of break this down and and write your own types of codes like this. So basically what I want to do is I want to write code that says when this element is clicked, show a message. So I'm first going to select that element with document that query selector. I'm going to select the paragraph tag on the page. And then I'm going to add an event listener. And I specifically want to listen for when this element is clicked. And then when it's clicked, I want to run the code inside of these curly braces. And in this case, I'm just going to throw an alert that says, "Hello world. You clicked me." Now, there are specific rules about JavaScript, like where the curly braces go and what you can actually listen for and how you should select things. We're not going to worry about the specifics of that. Just know that this bit of code makes it so that when this element is clicked, a message will pop up. Now, just like we added a link to the styles, we also need to add a link to the JavaScript. And this is done with a script tag. And then we set the source attribute to be the name of the file. So app.js. Now I didn't mention what attributes are earlier, but essentially we have our tags. And then each one of those tags can have attributes. So re is an attribute with a value of stylesheet. Href is an attribute with a value of styles.css. And source is an attribute with a value of app.js. So this tells the web browser when it reaches this line of code, it should make a request to retrieve that app.js file. the server is going to respond with the contents of that file and then the web browser is going to run that code. So, let's give it a try. If we head back over here, we can see the page refreshed and it actually did make that request for app.js. And when I click this paragraph tag, look at that. We get an alert that says, "Hello world, you clicked me." And so, just like the other two files, the web browser requested the HTML, it got back the source code. It requested the CSS, it got back the source code, applied it to the page. It requested that JavaScript, it ran it, and now it's just waiting behind the scenes waiting for that element to be clicked. So again, if you want to learn more about JavaScript, MDN is a great resource. They also have like the introductory guide, intermediate, all the things that you can do with JavaScript. They describe it here. Of course, there's lots of other resources I'll talk about at the end of this video as well. But these three things, CSS, HTML, and JavaScript are what make up web pages. Every single web page you visit, no matter where it is or where it's at, if you're visiting it in a web browser, it's made up of CSS, HTML, and JavaScript. Now, the next thing I really want you to think about here is where is the code running, right? We wrote this code on our computer, this HTML file, this JavaScript file, this CSS file, and we're running a static file server. That server is sending these files to any client that requests them. But that server is not running these files. It's not building out the web page and and running the script and applying the styles. That server is literally just giving the files back to whoever requested them. In this case, the web browser requested them. And it's the web browser's job to actually display the web page. So the web browser literally receives this HTML and then builds out the page and literally receives the CSS and applies it to the page and then literally receives the JavaScript and then runs it on the page. And so this is the main thing I want you to take away from building static websites like this or front-end websites is the code does not run on the static file server. It runs in the user's web browser. So when you're building websites out this way, like I mentioned, this is known as front-end development. we are building out what the end user sees, but that code that we write is running on the end user's computer. It's running inside of their web browser. So even though we're we're writing this code for selecting elements, that code doesn't actually run until it gets loaded into the end user's web browser. And so if anybody else goes to my website, all three of those files will be received by the web browser, run internally, rendered out, styles applied, and the JavaScript runs locally inside of their web browser. And so like I said, this is front-end development. This is a static file server. There's nothing special or unique happening when a user visits our website. It's literally just receiving the files as we wrote them and then rendering them out in the web browser. Now, this static file server that lives in here in VS Code, which we installed as an extension, is what's known as dynamic code or serverside code or backend code. So, this is actual code that says when I receive a request for a file, I'm going to read that file in and then send back its contents. So, that's what we're going to talk about next. this difference between frontend and backend and this idea that we can write code that actually runs every time a request comes into our server because that's where things get a lot more interesting, right? We're not just writing these files ahead of time that then get rendered into the user's browser. We can write logic that runs every time someone visits our website. And that's what we'll talk about in the next section. Now, the website we just wrote was using three languages, HTML, CSS, and JavaScript. And those are all known as client side languages or languages that are meant to be run inside of a web browser. There are also programming languages that run directly on a computer. They don't run inside a web browser. And that's what we're going to talk about now. Because if we want to build out our own custom computer programs that respond to incoming requests from clients, we're going to need some general purpose programming language that runs directly on a computer. And so earlier when we ran that NC or that netcat command from the terminal, that was just a manual way of of defining essentially a server that could respond to incoming requests. But if we use a programming language, we can write code that does this automatically. And so you can take a look at the Wikipedia page for programming languages. There's a lot of them. There's also this page here called list of programming languages. But essentially what we need is a general purpose programming language that can build HTTP servers to respond to incoming requests. Now the one that I'm going to show you an example of and how to use in this video is NodeJS. And what's cool about Node.js is you can write your serverside code using JavaScript. So it looks exactly the same as the JavaScript we wrote earlier that runs inside the web browser. But this JavaScript code runs directly on a computer and it can create programs that actually listen for incoming requests and can send responses. And that's why this is a pretty popular choice because you can learn one programming language and then use it for both the client and the server. Some other choices or some other things to look into are PHP. This is old faithful. It's been around for a very long time and and you can write code that essentially runs on a server. PHP code executes and can send responses to the client requests that are coming in. Of course, there's Python, another really popular programming language. They have built-in ways of creating HTTP servers. There's also C, which is used a lot in enterprise or at larger companies, but you can build web servers with C. There's also Java. You can take a look at something called Ruby on Rails. There's also Go. So, there's a lot of choices when it comes to building HTTP servers. And it really just comes down to preference and also what you're familiar with and maybe even just what your job is using. So ultimately just pick one um and build out your servers using that. And of course like I mentioned we're going to be using NodeJS for this. So what you should do is head over to the download page and then make sure you choose the right operating system. Follow the steps for installing. Once we have Node.js installed, I'll show you how we can write our own custom program that responds to HTTP requests. So now with Node.js installed, we're going to create a new website that is just serverside code. So here inside of VS Code, if I press command shiftp or control shiftp, I'm going to choose close workspace. So that's going to close that folder. And then I want to open and create a new folder that's just going to have our serverside code. So I'm going to go to open folder. And then here in documents, I'm going to create a new folder that's called my first server. And then I'll open VS Code in that folder. I'm going to trust the author because I am the author. And in this folder, I'm going to create a new file called index.mjs. Now, if we head back to the NodeJS website, they actually have an example that we can just copy and paste. So, I'm going to copy this code to the clipboard. I'm going to paste this in here. And this is code that will actually spin up a server that is listening for requests on port 3000. And anytime a request comes in, it's just going to immediately respond with hello world. Now, in order to start this server, I need to run this file with Node.js. Here inside of VS Code, if you open up the command pallet, you can search for toggle terminal. And this will open up the terminal inside of VS Code. This is similar to the terminal we had open earlier, but now we can use it directly inside of VS Code. Now, again, this is not going to be a full tutorial on on terminals. There are other videos and courses for that. But if I do an ls, we can see there is that one JavaScript file. And if I want to run it, I can type node and then the name of that file. If I hit enter, now that server is running. It's listening for requests. So if I head back over to Google Chrome and go to httplohost 3000, the server responds with hello world. So this code right here is running and it's just sitting there. And anytime an HTTP request comes into the server, it's going to immediately respond with hello world every single time. So if I refresh the page, we get back Hello World. We get back a hello world. We get back Hello World. Amazing. Now, this server can do more interesting things. So instead of just saying hello world, what if we actually put the current time on there? So I'm going to do date now, which is going to give us a time stamp for when this page was created. I'm going to restart the server. And now if I request it, you'll see a number there. But now every time I request this page, I'm seeing the latest time. That's essentially when that code ran. And so this is the next type of server. This is a dynamic server. Instead of just being a static file server, that is a server that just immediately sends back files that are requested. It can do interesting and dynamic things based on the incoming request. Now, another thing we can do is we can look at the incoming path, right? Let's say somebody goes to /hello. Right? Now, it's always responding with the same thing. But I can write code that says if the path that's being requested is /hello do something else. So here I can write custom logic based on the incoming request. So for instance I can say if the request URL is equal to/hello then I can send back something different right I'll copy this and then I'll just say you requested the hello path. Else do what we were doing before and just respond with hello world. And now if I start my server back up, when I request the homepage, I get hello world. But if I request /hello, it says you requested the hello path. So I can write code that runs every time a request comes in and then does something interesting or unique. And so given what I've just shown you, try to imagine how the server was written that we were using earlier, that static file server. Essentially, when it receives a request for index.html, HTML, it would write code that literally reads in the contents of index.html and then responds with that actual HTML code. And then if it received a request for styles.css, it would read that file in and then respond with it. So we could write a static file server that behaves that way. Essentially list the files in the directory. If that file exists that they're requesting, respond with it. That is how a static file server works. But this is much more interesting because instead of just responding with files, we can basically run custom code on our server anytime a request comes in. And so to get back to our question of where does the code run, it depends. If it's a static file server, that code is just reading in the files and responding with them. The code at the end of the day is going to be running inside of the web browser. If it's a dynamic server, then it can actually run code when a request comes in and it can do interesting things. It could reach out to other servers or it could talk to a database or it could read files or it could have custom logic depending on that incoming request. And that really is the magic of this client server model and this request response model. Instead of just working with files, now we can do more interesting things. And at the end of the day, we can still think of these things as paths and endpoints, but we can actually have dynamic code that is running custom instructions for every single request that comes into our back-end server. And so this is known as the backend. It's code that's running on a server to respond to requests and can do interesting and dynamic things. And so now let's actually combine these two websites. So we can actually write a server that responds with static files if those static files are requested. but it can also have some more dynamic endpoints that do interesting things when a request comes in instead of just responding with a file. Now, for this I am going to close out this workspace and we're going to create a brand new one and I'm going to create a new folder here called my first full stack website. So, this is going to be a website we define that has both a front end and a backend. So, we'll open this up and I'm going to trust the authors. And now I'm actually going to define two folders inside of here. I'm gonna have the public folder and this is where all of my static assets are going to go. This is where my HTML, my CSS, my JavaScript, the things that are going to ultimately run in the web browser on the other side, those are going to live in this public folder. And then I'm also going to have a folder called src or source. And this is where all the source code of my server is going to go. So I'm going to add inside of here an index.mmjs file. And this is going to define my server side code. Now, it would be very cumbersome if I had to write all of that conditional logic like we saw in the last example for defining a server like this. And it's possible to do, but we do it so often that instead of having to write this code ourselves, we can use what's known as a library. Essentially, somebody else wrote all that code for us, and we can now bring it into our app and benefit from it and expand on it. And in the world of Node.js, we use a thing called npm. And this essentially is a repository of many different packages that other people have written that we can use ourselves. One of the most popular libraries for doing this thing for building out web servers is called Express. So we're going to use this library to build our full stack website. So from here I'll open up the terminal. And first I need to initialize this as npm. Now like other aspects of this video, you don't necessarily need to follow all of this. You also could just watch to see what happens here and then go off and find other resources that dive deeper into how all of this stuff works, but I will explain what's happening. So, if you want to try to follow along, feel free. This package.json just got created when I ran this command. And essentially, this is going to list my dependencies. That is packages that I want to use to build out my web server. Now that I have this, I can do npm install and specify the name of what I want to install. And essentially this name needs to match something that exists on the npmjs.com website. So here you can search across all the available packages. I in particular want to use this express package. So I'm going to run this command that's actually going to download it and give me access to it. So now you can see that it's listed under my dependencies. That means I can use it in my own code. So now over here in my index.mmjs I can actually just run this codes here and you'll see it looks a little bit similar to the code that we had last time but it's a little bit higher level. Things have been abstracted away and essentially what this says is if our server receives a git request on the slash route we're going to respond with hello world. Pretty cool huh? And so if we want to replicate what we were doing before, we can also say if we receive a git request on /hello, we can respond with this is the hello path. Right? So this express library basically makes it so that we don't have to write all that extra code. They've abstracted away the nitty-gritty details and make it much easier for us to define this serverside code. So with this we can now try and run it. If I do node, we can specify the source directory index.js. It now starts up. It's running on port 3000. And so if I visit localhost 3000, you can see that it renders out the hello world there. And then if I go to /hello, it says this is the hello path. So I now have a much easier way of defining my serverside codes. Now let's write some code that actually does serve up static files. So one thing I'm going to do is I'm going to copy over that HTML, CSS, and JavaScript file that we defined earlier for our first static website, and I'm going to put it into this public folder. Now, I am going to use the command line to do this. You could do it manually with the file explorer, but essentially I want to copy from my first website. I want to copy everything that's in there, and I want to put it into this public folder. And just like that, that index.html, that app.js, and those styles.css, all of those got copied into this public folder. Now, I want to write some code that says when a request comes in, if the file exists, just send back that file. there's no no need to run any dynamic code. Just send that file back. So right here I will say app.use and I'm going to use the built-in static middleware. So if I say express.static, I can specify the name of a folder and all of that code is just built in. Basically this says if a request comes in for a file, check to see does that file exist in the public folder. If it does exist, respond with that file. Now just like this, my server is just going to serve up those static files. So, let's start this thing back up. And now, if I head to localhost 3000, it loads my website. Now, let's take a look at what's happening here. Let's take a look at the network tab and see all the requests that happened. So, let's clear this out, do a refresh, and you'll see a request came into my server running on port 3000. It responded with this index.html file. And so, this is something that happens by default. Essentially, if a request comes into the slash route, most servers automatically default to serving up that index.html file. So because this exists right here, it's automatically going to serve that up. Then the web browser saw this link to the CSS. So it made that request into my Express server and responded with the CSS. And then in the HTML, it also saw that there was a link to app.js. So it requested that file from my express server and then it responded with that file. Now to really show you what's happening here, I'm going to add some more code in my server side that actually can see every incoming request. So this is known as a middleware. And then basically I can keep track of every request that comes into the server. So I'm just going to log this out what the incoming request is for and then allow the next thing to happen. And so if I kill and restart my server, I should see every request that comes into the server. So if I refresh the page, you'll see the browser requested the slash route. The browser requested styles.css. It then requested app.js. It then requested this weird dev tools theme. But every single request that the browser made here, we can actually see came into my server and then got served up by this static middleware. So we've we've come full circle. We have written our own code that in turn is serving up static files that the browser is rendering. And now we can actually combine and do both things. So not only can our server serve up static files, we also can serve up dynamic routes. So for this, I'm going to add a new endpoint that says when a request comes in to slashinfo. I'm going to respond with some dynamic info about myself. And this endpoint is actually going to respond with data that we can then use on the front end. So here I'm going to say res.json, meaning I'm going to send back some JSON data. I'll tell you what that is in just a second. But I'm going to send back my name that'll exist inside of there. I'm going to send back the name of my dog, which is Panzer. And then I'm going to send back the current time and date, which will just be date.now. Now, another thing I can do is keep track of how many times this endpoint has been requested. So, I'm gonna have a variable called count. That's going to start off as zero. And then every time this gets requested, I'm going to increment that by one. And I'm going to include that count in my info data here, like so. Now, when a request comes into slashinfo, it's going to respond with this data. and count should increase every time and date should be different every time. So I'll need to kill my server, restart it, and now if I refresh the page, it's good to go. But if I go to slashinfo, that is now going to give me back that data here. And you can see Chrome has this option for pretty print because it recognized that this is JSON data. And uh it now we can actually see that. And so if I refresh this, we can see the count goes up. The date changes every time it's requested. Okay, fine. What I can do now is combine the two. So I can write code that runs on the client that actually requests this data from the server. This is where things get really interesting. So here in my app.js when this page loads, I actually want to request this data from slashinfo. So remember this code here runs on the client, right? It runs inside of the web browser. So basically I can write code that says let's fetch slashinfo. This will give us the HTTP response. We can then parse it as JSON and then that gives us the data itself. And for now, I'm just going to log it out. Now, again, you don't have to understand what all of this is just yet, but just the general idea that I'm combining the two. This code is going to run inside the web browser. It's going to dynamically request this data from the info endpoint and then it's going to display it in the dev tools. So, let's give this a try. I'm going to click on the console here and we're going to go back to the main website. And we do get a syntax error, but to fix that, we're going to go and change this to a module. So in our index.html, I'm going to set the type here to module. And now if I refresh the page, there we go. So when the page loads, it makes the request to slashinfo. It gets access to that data and then logs it out here. And if we look at the network tab, we can we can see what happened, right? The browser requested the HTML. It then saw styles. It requested those. It then saw app.js and requested each one of those. It then ran the code inside of app.tjs and the browser saw this piece of code that says, "Oh, make a request to slashinfo." So, it did that too. And you can see that it makes a git request to slashinfo and then gets back that response. Uh, and now we can do some pretty interesting stuff. Now, we can take this data and actually display it on the web page. So, let's just add an element right here. We'll call it, we'll do another p tag, and we're just going to give this an ID of info. And then in our client side JavaScript after we've gotten back that JSON, I'm going to select that element. So the element with ID info, and I'm going to set its inner HTML to be some some custom HTML here. So I'm going to have an H H3 that says my name is, and then I'm going to render out JSON.name. I'll have an H4 that says my dog is. We'll render out my dog. I'll then have an H5 that says uh today is. And then we'll do JSON date. And then lastly, I'll do an H6 that says this page has been requested. JSON.count times. Now again, you don't need to understand any of this code. Just understand that when the page loads, it's going to make the request to info and then dynamically update the page to include some new HTML. And so this really is the power of JavaScript running inside of the web browser. So if I refresh this page, would you look at that? the data actually gets rendered out. So my name is CJ, my dog is Pancer, today is this particular date. If we want it to be displayed nicely, we can actually throw this into a date constructor and then that will show it as an actual time stamp. Um, and it says this page has been requested nine times. And so every time I refresh, the date and time is changing. The number of times it's been requested is being updated every single time. This is the power of full stack development. And so basically this code runs on the server when the request comes in. This code runs on the client inside of the web browser when the page has loaded. And so every website you visit across the web as you're navigating around as things are changing. This is essentially what's happening. You have some code running on a server that can do things dynamically. You have then code that gets sent to the browser that's run internally. It can do dynamic things and update the page itself. And then it's just this constant request response cycle back and forth to give you these dynamic experiences across the web. Now, one of the things I showed in that last example was JSON. And JSON is a data format. It is an open standard and it's essentially a way of describing data. You saw in my example, we had what were called key value pairs. So it had name CJ, dog, panzer, count some number, date, some number. And so this is a standardized way of representing data and every single programming language speaks JSON. So it has code that can read JSON in and then we can operate on that JSON code. And as you saw in the front-end code and the backend code that I wrote, we could write code that creates JSON and we could write code that actually reads from that JSON. So as you build out websites, typically if you need to share data in some way, it often is represented as JSON because that could be interpreted in a lot of different places and is directly supported inside of JavaScript. It's it's actually short for JavaScript object notation. And so that's why it's so easy to work with when we're building out our backend applications with JavaScript is because it's just native to the language. Now with that said, I want us to start to think about this idea of APIs or web APIs. And so this slashinfo endpoint that I wrote could be seen as a very simple web API. Essentially, when a request comes into this endpoint, I'm always responding with JSON data. I'm not responding with HTML. I'm just responding with data. And then whatever client application is receiving that data can kind of do whatever they want with it. And so this is a very primitive example of a web API. There are lots of other web APIs out there. And essentially a lot of businesses and companies make their data available via web APIs. So you can write applications that pull data in from Reddit or from Instagram and use that data in your application. And then they also have APIs where you can send them data. So you could write custom applications that are interacting and interfacing all across the web in this way. And so web APIs are really the generalized connector of the web. It basically allows us to exchange data in a common format and reuse it across the web. Now, as I showed, you can write your own web APIs that operate on your own data or you can mash them up with other web APIs. I have this resource here. It's called public APIs. And this is just a gigantic list of a ton of web APIs available across the web that have things like animal related data or anime related data or art and design and blockchain and books and all of these various data sources that make themselves available via web APIs. So you can write code that pulls that data in and and mix it up and mash it up and basically make your own custom web applications that use that data. Now, not all web applications that have been built have open APIs, meaning they might not have been written in a way where they want you to know what endpoints are available and they don't necessarily want to make that data available to other websites. But there are some that are publicly available and this list is a good place to get started. Now, another aspect of these applications that we build out are databases. And this is essentially a way to store lots and lots of data and be able to query that data as well. Now in the simple program that I wrote, I just hard-coded that object uh which is data directly into my program. But we might have applications that has have a ton more data than just that. So if you think about for instance the the website Reddit, they have posts and so they would need to store information about every post. When was it posted? Who was it posted by? What's the title of the post? What's the text of the post? How many comments are on the post? For each comment, who was the author? What was the text of that comment? Did that comment have any images? There's all this information associated with just giving you back the information for any given post on the Reddit website. And all of that information is likely stored in a database. It's essentially long-term massive storage for information that can be dynamically queried and then eventually brought into and displayed on web pages. Now, I'm not going to show you any examples because this video is getting way too long. But there are lots of different kinds of databases. And essentially, we can write code on the server that directly interfaces with databases. It can retrieve data from a database. It can put data into a database. And this is how we start to get much more rich and expansive applications because we can store data from thousands and thousands of users. And we can let each user have a unique experience because they have unique data stored in the database that's tied to them. So, I'm not going to show you any examples with it, but just know that databases exist. And this is essentially how we can store things long-term and make for more interesting full stack web applications. Now, at this point, I would think that you have a much better idea of how all of this stuff connects together. And I want to leave you with some road mapaps like where to go from here and and how to find out more about all this stuff beyond what I just showed you. And one of the best places for this is roadmap.sh. It essentially has road mapaps for all the different types of development that you might want to get into. Now in this video we kind of leaned into web development and this idea of full stack development and HTTP requests and the worldwide web. There are other types of development where essentially you can write programs that are that only run on specific types of computers and aren't web applications. That's that's also a possibility. For instance, games. If it's not aorked game, meaning it's like it's not meaning it's not a multiplayer game, you could write a game that only runs on Linux or only runs on Windows and has nothing to do with the worldwide web. That's a possibility as well. And a lot of these skills do transfer over. But all of that to say, Roadmap.sh SH is a great launching off point for any one of those types of things. So in particular, if you are interested in game development, they have a game developer roadmap and you can click into this and you can see all the possible topics that you might explore. So they have a section on client side development and the idea of client server would still apply here but it may not be in the context of web applications. might be each instance of a game running is a client and then you have a server that orchestrates things and make sure that multiplayers can see each other and and it might even keep track of the overall state of the game. But then when you're getting into graphics, you might care about things like vectors and matrices. Um and then there also game engines and physics and so this road map looks daunting but it kind of at least will guide you if you want to start to learn about these things. Similarly, they have road maps for front-end, backend and full stack. Those are the things that we focused on in this video. So if you click on front end, you can see that it starts off with HTML, CSS, and JavaScript just like I showed you, but there are other aspects. So we talked a little bit about package managers. There are other libraries. So I showed you a library for working with server side code. There are also libraries for working with front-end code. So instead of having to write out all your JavaScript manually when you're building out frontends, there are frameworks like React or Vue or Angular or Spelt or Solid that make it a little bit easier. and basically take what is usually fairly cumbersome and turn it into something that requires less code and is more consistent. And so a lot of the code that is output by Vzero or Lovable or any of these vibe coding tools very often is React code. And so if you want to understand React, you first need to understand JavaScript and then you can start diving into React. And then that also gets into uh TypeScript. Is TypeScript mentioned on here? Yeah. So there's a a type checker down here talking about TypeScript, but actually TypeScript is fairly important in this whole ecosystem. So you might even learn that earlier. It gets tricky, but this does give you an idea of what you might need to learn and and in what order. And you don't need to learn everything. I think the way that I like to approach stuff like this and how I've approached it my entire career is I learn it as I need it. Essentially, I'm trying to solve a problem. I'm trying to build a specific type of app or solve a particular problem in my life and I learn just enough about a given language or a given framework to get that thing working and then I move on with my life and then later on maybe I can call back to what I learned. But I would suggest that you don't try and learn everything. Just learn enough to build the things that you want to build. You'll also see on the front end road map they talk about some of the stuffs we we were we were mentioning like HTTP but then they get into things we didn't get into like DNS. So check out the frontend road map. There's also the backend road map which talks about some of the stuff we talked about. So you have all these various different programming languages. You might pick one from there. You might pick a database. There's different ways of building out APIs and other concepts like caching that you might need to worry about. So definitely check that one out. And then the full stack one kind of ties all of this stuff together. And so this is like a road map of road maps. It it shows you how you can tie together those front end and backend concepts which we did in this video but at a very high level. So from here, I highly recommend pick a path. If you're going to stick with frontend, backend, and full stack, I have some specific resources for that I'll share with you next. But if maybe you want to learn about other things in the world of programming, there are tons of other jumping off points here on the road map website that will get you started. Now I want to talk about some specific resources for learning front-end, backend, and full stack web development. The first one, this is a triedand-true resource, freecodeamp.org. You can see that they have a responsive web design certification, a JavaScript certification, a front-end library certification, Python, relational databases, backend development. So, they have courses for all of the different types of web development that you might want to get into. And the nice thing about Free Code Camp, depending on how you look at it, is it very much holds your hand. And let me show you what I mean by that. So if we go into the very first lesson on HTML, it actually gives you a place to write out your code and then it has a button you can click to check your code and you can actually preview it here in the web browser. And so this is a very guided way of learning about web development because it's all happening inside the web browser. And the thing about this is you're less likely to hit the the bumps and the issues that you might run into if you're trying to run all this stuff locally like I showed in this video. And so that's the one thing that isn't the best I would say about Free Code Camp is it's not as close to the real world as you would get if you were like working a job and doing this because when you're doing it yourself, you're writing all the code locally. You're running all that code locally. You're in complete control of everything. Whereas when you're using Free Code Camp, you're plugging all of your code into this custom editor they have here. And they have nice quizzes that that run against your code. And so it's nice from the aspect that you don't have to think a lot. and it kind of holds your hand, but that's not as close to what you're actually going to be doing in the real world when you're writing all of this code yourself. So, Free Code Camp is a great way to get started, but you definitely need to graduate to writing the code yourself eventually. Now, one good way to do this is with CS50's web programming, Python, and JavaScript course. So, CS50 is a course on more general programming across all types of things, and their CS50W is specific to web development. And so this gets into a lot of the things that we were talking about with front-end development with HTML and CSS, but then they also show back-end development with Python. And the course materials and everything is available for free, but if you want the certification, you do have to pay for it. But all of those resources are free. And this one doesn't hold your hand. Essentially, you're given assignments, you're given resources, you need to read, you need to watch the lectures, and then go off and do the work yourself. So it's good in that aspect. And then there is the Odin Project. And in my opinion, this is one of the best ways to learn all of this stuff because it doesn't hold your hand. So you can click here and see they have a few different curriculums. They have foundations and then they have full stack Ruby on Rails and full stack JavaScript. I recommend going through foundations and then going through full stack JavaScript because it'll be very similar to the stuff that I showed you in this video just much more in depth. And the thing I like about the Odin project is it doesn't hold your hand. So for any given course, let's say we go into the JavaScript course and then let's say we go into a lesson on objects and object constructors. The thing about the Odin project is it will give you an article that kind of describes and teaches the concepts that you're attempting to learn. And then you'll also be given exercises. So things these are things that you need to go off and do yourself to verify you understand what you just learned in this article. And then there also are assignments and these are projects that you'll go off and do or things you need to read to dig deeper and learn more about this particular topic. But this doesn't hold your hand, right? It's not just a text box in the web page. You literally need to go to some other website and read or you literally need to actually build a thing outside of the page itself. So it really makes you get hands-on and and learn this stuff directly instead of just being directly guided in the browser. And of course, there are also knowledge checks. And so, this is one of the hardest parts when you're self-learning is checking to see, do you actually understand the thing that you were just taught? And the way to do that is with knowledge checks or checks for understanding. Essentially, can you answer these questions without looking at any resources? Did you actually internalize all of the topics that were covered in this particular section of the course? And so that's the other nice thing about the Odin project is it's up to you to make sure that you do have this knowledge and that in and of itself is a skill. Like being able to validate your own understanding is something that you really need to practice especially in the age of AI where you can ask AI. It'll give you an answer but you don't really know is it the right answer. And so if you get better at these knowledge checks, you're going to get better at being able to verify the output from AI. So that's why I really like the Odin project. It's really in-depth, tons of sections, and then it really makes you work. So, if you're ready to put in the work, the Odin project is definitely the way to go because it's as close as possible is what you're going to get to actually building and working in the real world of full stack web development. Now, I have just scratched the surface, right? I just really exposed you to a lot of these ideas. Now it's up to you to go off and dig deeper and learn more. Right? Take a look at the programs that AI has output for you and try to see do you actually understand the code or can you break apart that code and figure out okay what's the front end? What's the back end? What is what's actually happening here and and dig deeper to understand it so that you don't have to depend on AI as much. Now, I hope this was useful for you. If it was, let me know down in the comments. And if there's anything you'd like me to actually dive deeper into, not just cover at a surface level, let me know down in the comments as well. Like I mentioned at the beginning of the video, I would really appreciate it if you shared this with people. That's the best way you can help. I All of this was free. There's no ads. You didn't have to pay for this. I'm just sharing everything I know about all the things that I know at a service level. But uh the best way you can help me in the syntax channel is by sharing this video. Share it with non-technical people. maybe link to a specific section that you maybe think other people could benefit from. That is the best way to help me and I would really appreciate it. All right, that's all I have for you in this one. Hopefully, I've uncovered a little bit. Hopefully, I've removed some of the mystery in how parts of the world work and how computers work. It's up to you to dive deeper, go off, learn more, and uh and build. So, I'll see you in the next one., Oops, You're a Programmer Now | a Guide, YouTube, 01kcks5mmwf0nq4q2y7hv8k846.