JavaScript for beginners

What is JavaScript actually for?

For whatever happens after the page has opened. JavaScript is the only language every browser runs natively, and its job is to bring to life the page HTML built and CSS coloured.

The figure at the top of this page is three gears, and it shows that division of labour. HTML says this is a heading and that is a button, CSS says what colour the button is, and JavaScript says what should happen when somebody presses it.

There are four jobs only JavaScript can do: reacting to what the visitor does after the page has loaded, changing something that is on the screen right now, talking to a server without reloading the page, and keeping something in the browser itself until next time. Anything else you think needs JavaScript is worth checking twice; section six of this lesson comes back to that with a concrete list.

There is also a job that is not its own and that beginners often confuse: JavaScript running in the browser is not a server side program. Storing an order, sending an email and checking a password all happen on the server. The browser code only makes the request.

Where do you write the code, and how do you attach it?

In a separate file with a .js extension, attached to the page with one line in the head:

<script src="app.js" defer></script>

That word defer is the most important thing in this section. It means download the file while the HTML is being read, but leave running it until the whole page has been built. Without it, a script sitting in the head runs before the elements exist and every attempt to find a button returns null. That is the most common beginner "why does it not work", and the answer is one word.

Your second tool is the browser console. Open it with F12 and keep it open: every JavaScript error is printed there with its line number, and console.log shows you anything you ask for. Until you have opened the console, you are coding in the dark.

const title = document.querySelector("h1");
console.log(title.textContent);

And variables: write const unless you know the value has to change, and then let. The word var is left over from an earlier era of JavaScript and there is no reason to write it in new code.

What is the DOM, and why does everything start there?

When the browser reads your HTML it builds a tree of objects from it in memory. That tree is called the DOM, and JavaScript works on it rather than on your file. That is why changing something in code updates the page instantly while the file on disk stays untouched; one refresh puts everything back.

Finding an element takes one function, and one is enough. document.querySelector takes the same selectors as CSS:

const btn  = document.querySelector(".btn");
const rows = document.querySelectorAll(".row");

Once you have found it, you have three everyday jobs. You change text with textContent, you add and remove classes with classList, and you set attributes with setAttribute.

btn.textContent = "Saved";
btn.classList.add("is-done");

Among these there is a decision worth learning correctly from day one. textContent treats whatever you give it as plain text, while innerHTML treats it as markup and acts on it. If the text you are inserting came from a user, you have handed that user the ability to write tags into your page. The rule is simple: unless you are genuinely building HTML, use textContent.

And one habit that keeps the work clean: instead of changing colours and sizes from JavaScript, add a class and let CSS draw the look. JavaScript changes the state, CSS shows that state.

Events: when the visitor does something

Everything the visitor does creates an event: a click, typing, submitting a form, scrolling. You tell the browser which event on which element you want, and which function should run:

btn.addEventListener("click", function () {
  console.log("someone pressed it");
});

Here is a complete example that genuinely works and is not possible in HTML and CSS: a character counter under a text field.

<label for="msg">Your message</label>
<textarea id="msg" maxlength="200"></textarea>
<p id="left">200</p>

const box  = document.querySelector("#msg");
const left = document.querySelector("#left");

box.addEventListener("input", function () {
  left.textContent = 200 - box.value.length;
});

Five lines, and several points fitted into five lines. We chose the input event rather than keyup, because keyup only listens to the keyboard and misses text pasted with a mouse or from a phone. value is the current content of the field and length is its length. And maxlength on the tag itself does the limiting; JavaScript is only showing the number.

Forms need one more event. If you want to handle the submission yourself, you have to stop the browser default behaviour:

form.addEventListener("submit", function (event) {
  event.preventDefault();
});

The next figure walks through that cycle step by step. What matters in it is the last step: you change the DOM, and redrawing the page is the browser job, not yours.

fetch: getting data without reloading the page

Up to here everything happened inside the page itself. fetch is where the page talks to the outside: you call an address, the server answers, and you put the answer on the page. All without a reload.

async function loadPrice() {
  const res  = await fetch("/api/price.json");
  const data = await res.json();
  document.querySelector("#price").textContent = data.toman;
}

The word await means wait for the answer and only then run the next line, and it only has meaning inside a function marked async. This is the first place JavaScript genuinely gets harder, because the work is no longer one line after another. If you got this far on day one, that is enough; the rest can wait.

Know three things now so you do not waste time. First, the address you call has to exist and answer; in the console, the Network tab shows whether the request went out and what code came back. Second, if the address belongs to another domain the browser blocks you from reading the answer unless that server allowed it. And third, the most important: this code runs in the visitor browser and they can read all of it. No key and no password belongs in this file.

How much JavaScript do you actually need?

Less than you think, and that is our position rather than a preference. A large part of what beginners do with JavaScript is something HTML and CSS now do themselves, better and with less code:

• opening and closing a section with details and summary, without a line of code
• basic form validation with required and type="email" on the field itself
• lazy loading images with loading="lazy"
• a modal window with the dialog element
• reacting to element state with hover, focus-visible and has in CSS
• a horizontal slider with scroll-snap, which also behaves correctly under a finger

Why this matters: every JavaScript file has to be downloaded, parsed and executed, and the execution happens on the same thread that answers the user touch. While code is running, the page does not respond to anybody finger. A heavy image lowers quality; heavy JavaScript slows the page down. If you want to see what that does to real site speed, the site speed page and the lessons of the speed path show it with measurements.

Now the boundary of that claim, which every recommendation has. If what you are building is a product rather than a content site, a dashboard or an editor or a live chat, then you genuinely need plenty of JavaScript and there is nothing wrong with that. We are talking about company sites, simple shops and blogs: there, every kilobyte you do not write is a win.

One example from this very page: the figures you see in this lesson are drawn with zero lines of JavaScript. HTML and CSS, that is all.