How a Web Page Is Built

Every web page you have ever used — a bank, a video site, this lesson — is built from the same three languages. They are not three ways of doing the same thing. They have three genuinely different jobs, and understanding the split is what lets you know which file to open when something is wrong.

Three jobs, not three options

A useful way to hold this: HTML is the building, CSS is the paint and furniture, JavaScript is the electricity. You can have a building with no paint and no power, and it still stands and can still be walked through. That is not a metaphor for its own sake — it is literally how the web behaves. Turn off CSS and a page becomes ugly but readable. Turn off JavaScript and it becomes static but still there.

This is why the order matters when something breaks. If a page looks right but does nothing, the content and styling arrived and the behaviour did not. You now know which of three files to open.

What HTML actually looks like

HTML is text with tags around it. A tag in angle brackets marks where something starts, and the same tag with a slash marks where it ends. Together with what is between them, that is an element.

<h1>Learn JavaScript</h1>
<p>Start from nothing and build up.</p>
<button>Start the first lesson</button>

Three elements. A top-level heading, a paragraph and a button. Notice that nothing here says what size the heading is or what colour the button should be. That is deliberate and it is the whole point of the separation.

Elements go inside other elements, and that is what gives a page its shape:

<article>
  <h2>Values and Variables</h2>
  <p>Eight minutes</p>
  <a href="/courses/javascript/values-and-variables">Read it</a>
</article>

The article contains a heading, a paragraph and a link. Because everything sits inside something else, all the way up to a single element that contains the whole document, the result is a tree.

That word will come up constantly, so it is worth making concrete. Each element has exactly one parent and any number of children, exactly like a family tree. It is what makes instructions like "find the link inside this article" possible to express — and later, in JavaScript, that is precisely the kind of thing you will be writing.

Some elements carry attributes, extra information written inside the opening tag. In <a href="/courses">, the href says where the link goes. Two attributes you will use constantly are id (a unique name for one element) and class (a label you can put on many), because they are how CSS and JavaScript find things.

What CSS adds

CSS picks elements out and describes how they should appear.

button {
  background: #5048e5;
  color: white;
  padding: 10px 18px;
  border-radius: 8px;
}

Every button on the page is now purple with white text and rounded corners. The HTML did not change at all. You could hand the same HTML to a different stylesheet and get a completely different-looking site — which is exactly what themes are.

That first word, button, is a selector: it decides which elements the rules apply to. You can select by element name, by class (.card), or by id (#signup). Remember selectors, because JavaScript borrows the same syntax to find elements, and knowing one gets you the other for free.

What JavaScript adds

HTML and CSS describe a page as it should be. Neither can respond to anything. There is no way to write, in either of them, "when this button is clicked, add an item to the list". That is where JavaScript starts.

const button = document.querySelector("button");
 
button.addEventListener("click", () => {
  console.log("Someone clicked it");
});

Do not worry about the exact syntax yet — you will write this properly in a later lesson. Read it as English: find the button, and when it is clicked, run this. That is the shape of an enormous amount of real frontend code.

JavaScript can also change the page: add elements, remove them, change text, switch classes so different CSS applies. And it can talk to a server for more data without reloading, which is what makes a modern app feel like an app rather than a sequence of pages.

How the browser puts it together

When the HTML arrives, the browser reads it top to bottom and builds the tree in memory. It then reads the CSS and works out which rules apply to which element. With both, it can calculate where everything goes and what colour each pixel should be, and paint it.

If it meets a <script> on the way, it runs it — and that script can change the tree it has just built, at which point some of the work is redone.

The end product is never a file. It is pixels. HTML, CSS and JavaScript are all inputs to a process whose only output is a picture on your screen, updated many times a second.

The live tree the browser holds in memory has a name: the DOM, short for Document Object Model. It starts as a copy of your HTML, but from then on it is its own thing, and JavaScript changes the DOM rather than the file. A later lesson is devoted entirely to this.

Seeing the tree as data

Your playground runs JavaScript on its own, without a page, so there is no real DOM to inspect here. But the tree is just nested data, and you can model it with the same nesting you saw in the HTML above. This is close to what the browser holds in memory.

That is the essential idea: elements containing elements, each with a type and some content. Once you can picture a page as data, changing a page with code stops feeling mysterious.

What to take away

HTML is content and meaning. CSS is appearance. JavaScript is behaviour. Pages are trees of elements, selected by name, class or id. The browser turns all three into pixels, and keeps a live version of the tree — the DOM — that your code can change while the page is open.

Next: what JavaScript actually is, where it came from, and everywhere it now runs.