How the Internet Works

You are about to learn a language that runs on the web. It is much easier to learn if you know where your code will live and what is around it. So before any JavaScript, here is what actually happens in the few seconds between typing an address and seeing a page.

None of this is difficult. Most of it is one idea repeated: computers asking each other for things.

Two computers, one conversation

The internet is a very large number of computers that have agreed on how to talk to each other. At any moment, in any conversation, each of them is playing one of two roles.

The client is the one asking. Your laptop, your phone, the browser you are reading this in right now — all clients.

The server is the one answering. It is a computer that is switched on, connected, and waiting for requests. That is the whole definition. A server is not a special breed of machine; it is a machine doing a particular job. Later in this course you will run a server on your own laptop, and that will make more sense then.

Addresses, and why we do not use them

Every computer connected to the internet has an address — a number, so other computers can find it. This is its IP address, and it looks like 142.250.183.14.

Nobody wants to remember that. So we use names instead: aniui.dev, wikipedia.org. A name like this is a domain name.

The system that turns one into the other is DNS, the Domain Name System. It is the internet's phone book. You give it a name, it gives back a number. That is all it does. It does not store the website and it never sees the page you end up looking at.

Your browser asks DNS once, then remembers the answer for a while, which is why a site you visited a minute ago starts loading faster.

What happens when you press Enter

Here is the whole sequence.

1. Step 1

   You type an address

   The browser splits it into a site name and a path within that site.

2. Step 2

   DNS finds the number

   The name is looked up and comes back as an IP address.

3. Step 3

   The browser asks

   It opens a connection to that address and requests the page.

4. Step 4

   The server answers

   It sends back a status code and the file you asked for.

5. Step 5

   The browser draws

   It reads the file and paints the page, asking for more as it goes.

The asking and answering follow a set of rules called HTTP. You do not need to memorise it. You only need the shape: a request goes out, a response comes back, and both carry a little extra information about themselves.

The S in https:// means the conversation is encrypted, so anyone able to watch the traffic in between sees only noise. Every site should use it, and browsers now warn about the ones that do not.

One page is many requests

This is the part beginners are most often surprised by, so it is worth being precise.

When the server answers, it does not send you the finished page. It sends one HTML file. Your browser reads that file and finds it mentions other things — a stylesheet, three images, a font, a JavaScript file. Each of those is a separate request, back to a server, for one more thing.

An ordinary page today makes somewhere between twenty and a hundred of these. They happen in parallel, in a fraction of a second, which is why it feels like one event rather than a hundred.

This explains something you have seen a thousand times: text appearing first and images filling in a beat later. The browser could not ask for the images until it had read the HTML that mentioned them.

What the server says back

Every response carries a status code, a three-digit number saying how it went. You have met some of these already without knowing it.

Code	Means	In plain words
200	OK	Here is the thing you asked for.
301	Moved permanently	It lives somewhere else now, go there.
404	Not found	I exist, but I have nothing at that address.
500	Server error	Something broke on my side, not yours.

A 404 is worth understanding properly, because it is the one everybody has seen. It does not mean your connection failed. It means the conversation succeeded — you found the server, it heard you, and its answer was "there is nothing here". A genuine connection failure never gets far enough to produce a number at all.

The 4 at the start means the problem is with the request. The 5 means the problem is with the server. That single digit tells you whose fault it is, which is more useful than it sounds when you are debugging later.

Where your code fits

There are two places code can run, and knowing which is which will save you real confusion later.

On the server, before anything is sent. Code here can read a database, check who you are, and decide what the page should say. The visitor never sees it.

In the browser, after the page arrives. Code here can respond to clicks, change what is on screen, and ask the server for more. Everyone can read it, because it was sent to them.

For most of this course, you are writing the second kind. Your JavaScript will arrive as one of those extra requests and start running inside the browser of whoever opened your page.

Try the vocabulary

Nothing here needs code yet, but the words matter, so here is a small program that models the conversation you just read about. It is only strings and functions — everything in it will be ordinary to you within a few lessons.

Notice the difference between the last two lines. One found a server that had nothing to give. The other never found a server. Those are genuinely different failures, and telling them apart is a real skill.

What to take away

The internet is clients asking and servers answering. Names are turned into numbers by DNS. One page is many requests. Every answer carries a code saying how it went. Your JavaScript is one of the things requested, and it runs on the visitor's machine once it arrives.

Next, a closer look at the thing doing all this asking on your behalf — the browser — and the three languages it reads.