The web, and your first page

Theory

Where we're going, and how the web works

Welcome — this is where you start building for the web. Before you write a single line, look at where we're going.

In this track you'll build the Cosmos interface — a NASA Picture-of-the-Day site — as a real, static page: semantic HTML, responsive layout, and a light and dark theme. Without a single line of JavaScript. You can open the files you'll grow toward right now: github.com/programuoki/cosmos — look at vanilla/index.html and vanilla/style.css, that's where we're headed.

Making that page come alive — the gallery filtering, a picture opening, the theme switching on a click — needs JavaScript, and that's the job of the next track, the client-side one. Here you build the page statically; there it's turned into a working app. No framework, nothing installed, no build step — just files a browser can read.

Three languages, three jobs. The whole web stands on three languages, and each has exactly one job:

HTML — what things ARE: a heading, a list, a form, a link.
CSS — what they LOOK LIKE: colours, spacing, layout.
JavaScript — what HAPPENS: clicks, fetching data, changes on screen.

Keep those three separate in your head and most of the work stays simple. Mix them up and nothing behaves the way you expect. All seven lessons of this track are on the first two — HTML and CSS. That's deliberate: a page that's well built underneath is easy to make interactive later; one that isn't is impossible.

What actually happens when you type an address

When you type an address, the browser sends the server a request for one file:

GET /index.html HTTP/1.1
Host: example.com

The server answers — with a status code and some content:

HTTP/1.1 200 OK
Content-Type: text/html

<!DOCTYPE html>...

200 means "fine, here's the file." The browser reads the HTML, finds the CSS files and images referenced inside it, and asks for each of those too. One page is many requests. You'll see them all with your own eyes in a moment.

Who decides what HTML means? The W3C and WHATWG publish the specifications; browser makers implement them. That's why the same page works in Chrome and Firefox — and why "it works on my machine" is a weaker defence here than almost anywhere else.

One question worth sitting with now: where does your code run here? Think for a second before you read on. — It runs in the visitor's browser, on their machine, under their control. Everything you write can be read, changed and switched off by whoever is looking at the page. That single fact explains half of what we do later.

Serve the folder, don't open the file

To see the page the way a real visitor will, you have to serve it — run a small web server in your folder:

npx serve
# or
python3 -m http.server
# or the "Live Server" extension in VS Code

Double-clicking the file (an address like file:///…) works today — but it stops working the moment you split your code into modules, which is where the client-side track starts: the browser refuses to load them straight off the disk, for security reasons. Serve the folder from the start and you never meet that wall.

When you run it, the address bar shows localhost:3000 (or :8000). That's a real web server on your own machine — nobody else can reach it, and it behaves the way the real thing will.

Why does a browser refuse to read a file from your own disk at all? — Because a downloaded page could otherwise read every other file in that folder. The rule that stops that is the same one that causes CORS errors later — the same idea, a different symptom.

Dev tools

Press F12 to open the browser's developer tools. Three panels matter most:

Elements — the page as the browser understands it.
Console — where your errors will appear (later, once there's JavaScript).
Network — every request, with its status code.

Keep this open the whole way through. When something doesn't work, look here first, and at your own code second.

One thing that confuses people at the start: the Elements panel is not your file. It shows the live page, including anything JavaScript changed. Edit it there and your file is untouched — refresh, and the change is gone. Useful for experiments, confusing if you don't know it.