So you think you can JavaScript? Part 2
The series that tells you what mommy won’t [about JavaScript].
You get the syntax now. You know the code will run in your web browser. You ignored the first part of this series and made a Hello World program anyways. You’re ready to move on.
You started to learn JavaScript but you never really waited to figure out where it fits in, did you? Well it’s the glue that holds the fabric of reality together. The world it exists in is called the web.
Let’s talk about the web. The web is basically just a bunch of computers talking to each other. Think of it as a network with its own set of rules that make it what it is. These rules govern things like what roles each machine plays in the big network, how they communicate amongst each other, and a lot of other stuff. But the rules that the web enforces change often and so they’re much more like guidelines than they are rules. They’re the sort of rules that are meant to be broken.
Due to the continuous changing of these rules, there are magical new experiences being added to the web every day such as virtual reality, web payments, interfacing with the human brain, and lots more. It’s kind of a big deal. If you ever meet someone who thinks the web isn’t really that powerful, you tell them that there’s now a headband that let’s you read brainwaves in JavaScript. When they say that it probably doesn’t work that well, you tell them it’s because they don’t have much brainwaves.
Let’s talk a bit about the roles that different machines fill on the web. There’s quite a few roles to be learned but we’re only going to cover the two major ones: the server and the client. That sounds familiar, right? You were told that it was some kind of communication architecture but then you heard more big words and some abbreviations like TCP and UDP and kind of just left it.
Well it’s kind of a big deal too. Server-client is a type of networking design pattern where an application is based upon the communication of two machines that play the roles of the server and client. Typically, the computationally expensive and secure operations (i.e. data manipulation and storage, communication between users) happen on the server. The basic user interfacing and experience operations happen on the client. In the background, the two communicate to create a seamless connection between the user interface and the secure operations. The end result is the application.
The web works in a very similar way. Some code is stored on machines and that machine is told to dish out the resources it is asked for. This machine is the server. Another machine is told to fetch some resources and display them. This machine is the client. The code that is transmitted between the two machines is called a website.
The program that dishes out data on the server is called the web server. The program that receives data and displays it is called the web browser.
At the end of the day, a website is just a bunch of data that is stored on the server and interpreted on the client. There’s one big implication to this process: the code of the website is never run on the server. It just doesn’t happen. As a result, people often think that websites must be very powerless in comparison to an application made in a “real” language like C/C++ that can do all those important things like read and write to files. Obviously, these things can’t be allowed in JavaScript since the server can send any code it wants and you’d just run it on your computer.
But there’s a simple workaround for this. Recall the server-client design pattern. If you want to do things that aren’t allowed in JavaScript, let JavaScript tell the server to do them and send back results.
That seems sort of confusing since I just said that web server is only sending files. Well it still does do the magical stuff. But in the web server-browser design, you would implement those operations in between the time that the server receives the request and the time that the server returns a response. For instance, if you receive a request for a resource called ‘login’, you can check the username and password that was received alongside the request against your database of users. Once you have a result (i.e. error or a success), you would put that result inside the code of the website and then respond with the new code. Until that result is ready, you can just hang the user. Because who cares about what happens to the user.
These systems become much more complicated when you want to care about your users. Once JavaScript masters you, it will teach you the ways of the force and how to use it to do extra stuff in between the processes of the browser and server like meaningful transitions. You can also create more efficient communication in between the server and the browser by allowing the server to change parts of the page without needing to re-send the entire page again. But we’ll get to that.
Now that you know about the different machines that exist on the web, you kind of have to know how they communicate. The communication protocol between web servers and web browsers is called the Hyper Text Transfer Protocol or HTTP for short.
HTTP is really quite simple:
- There’s two types of data: requests and responses.
- Each HTTP data packet starts with a bunch of information about the request or response. This packet of data at the top is called HTTP headers.
- The first line of every request defines three things: the request method (which defines what we would like to do with the resource/if we are sending any data), the resource path, and the HTTP version that will be used to communicate (currently, most HTTP traffic happens in version 1.1 but is switching over to 2.0 which is epic).
- The first line of every response defines two things: the HTTP status code (there’s a long list of these that speak to the success of the response) and the common description for the status code (i.e. “Not Found” if the HTTP status code is 404).
After each header (including the first line which isn’t a header), there is a single end-of-line (EOL) character. This is \r\n on Windows and \n on *nix.
Side note: If you don’t know how EOL works, there is a set of regular characters (i.e. everything from a-z, punctuation, anything readable) and there is a set of special characters (the blank line that separates paragraphs, unreadable characters, emojis, etc.). Escape sequences always start with a \ (backslash) and are followed by a single letter defining the special character to be printed. n means line feed (LF) and r means carriage return (CR). The newline effect is basically the way in which you can hit ‘enter’ or ‘return’ and your text will jump to a new line. The way it works on *nix systems is that the LF character will cause a newline. But Windows is backwards so it requires a CR right before the newline (which just sends the cursor back to the beginning of the line). Therefore, hitting enter in Windows produces a CRLF and on Linux produces an LF. For the purpose of standardization, HTTP always uses \r\n (it’s an internet standard, many protocols do this). For more info, see wikipedia.
Let’s dive a bit into types of HTTP requests:
- ‘GET’ requests are meant to fetch a resource. They cannot include extra data outside the headers from the client-side. We will talk about how to transfer extra data from client to server in a GET request at a later time.
- ‘POST’ requests are meant to send data from the client to the server. They are accompanied with a response but the response is based upon what happened after the data was sent. For instance, a login form might use a POST request to send the username and password to the server. The server would then verify that the pair of credentials is correct and it might send back a “You are logged in!” page back or it might send an error along with the same login page back.
There are more methods but these are the main methods you need to be concerned with since they appear even before you start JavaScript.
Here’s a sample GET request for you to feast your eyes on:
GET / HTTP/1.1
Host: www.example.com
User-Agent: Some Web Browser v1.0
Accept: */*This is a request fetching the resource at ‘/’ using a get request. The HTTP version is 1.1, the hostname of the website is ‘www.example.com’, etc. You can read more about the different HTTP headers online.
A possible HTTP response to the above response would be:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Location: http://www.example.com/
Content-Length: 1024(The code at '/')
Alright, so then the web server will host my JavaScript code and it will respond with it to the web browser when it is requests it which will happen as a GET request and then the browser will run it? Okay, can I create my Hello World now?!?!
See you next time.
