How JavaScript works

The third language

HTML says what things are, CSS says how they look, and JavaScript says what happens. It is the only one of the three that can decide — read what a visitor typed, react to a click, change the page after it has loaded.

A script is a file of instructions, and the page brings it in with a <script> tag. The browser reads it from the top, line by line, the moment it reaches that tag — the same way Python reads a program, except the page is already on screen while it runs.

It is also the only one of the three that can be switched off. A visitor with scripts disabled still gets the HTML and the CSS, so the page should make sense without the behaviour, and the behaviour should add to it rather than replace it. That habit is called progressive enhancement, and it starts with putting the words in the markup.

A script that says something

console.log("Hello from the page");

const name = "Ada";
console.log("Hello, " + name + "!");

Where the output goes

On this page, console.log prints to the console pane under the preview — the black strip that also shows errors. In a browser tab you would open the developer tools to see the same thing; here it is already open.

That matters more than it sounds. JavaScript has no window to print into the way Python does, so the console is how a program talks while you are building it — and how it tells you what went wrong when a line cannot run.

Errors point at a line

When a line cannot run, the console shows a message and a line number. A misspelled name gives "is not defined"; a missing bracket gives a syntax error before anything runs at all.

Both are normal, and both are information. The line number is where you look first — and a console message you do not understand is usually one search away from being one.

What the browser does with the file

The browser reads an HTML file from top to bottom and builds the page as it goes. When it reaches a <script> tag, it stops and runs that file before carrying on. That is why the examples here put the script at the end of the body: everything above it already exists, so the script can safely look for it.

Order matters between scripts too. The first file finishes before the second begins, and a name declared in one is visible to the other only when they share the same global scope. A script that runs before an element is parsed cannot find it — querySelector answers null, which is a quiet failure rather than a loud one.

Two kinds of failure

A syntax error is found before anything runs: a missing brace or quote means the browser cannot turn the file into instructions, so the whole script is skipped. A runtime error happens on a line that was actually reached — the lines before it have run, and the lines after it will not. That difference tells you where to look first.

The console is also literal about what it prints. A string appears without quotes, so console.log("5") and console.log(5) look identical in the pane. typeof is how you ask which one you have, and the answer is the subject of the next chapter.

The console is a tool, not the page

A console.log line is for you, not for the visitor. It appears in the developer tools, which most people never open, and it disappears when the tab closes. When something needs to be read on the page, the script has to find an element and write into it, which is what the later chapters do.

That distinction explains a common confusion: a script that logs the right answer can still look broken, because nothing visible changed. While you are building, the console is the faster place to check a value; when the program is finished, every message a visitor needs has to live in the document.

Try these next

• Log typeof 5 and typeof "5", and compare the two answers in the console.
• Declare a name, then misspell it on the next line. Note which line the error points at.
• Remove a closing brace and run the script again. Nothing runs at all, because a syntax error stops the whole file.