Why Doesn't Clicking a Button Do Anything?
Open any plain HTML page you have written before — a page with a heading, a paragraph, and maybe a button — and click that button. Nothing happens. The button looks like a button, it even changes color slightly when you press it because of the browser's default styling, but nothing on the page actually changes. Look at this page:
<button>Mark Present</button>
<p>Status: Not marked</p>You can click "Mark Present" a hundred times. The paragraph will still say "Status: Not marked," forever. This is not a bug. HTML was never designed to react to anything. HTML only describes what should appear on the page once, when the browser first reads it — a heading here, a paragraph there, a button in the corner. It has no memory of clicks, no way to check what you typed, and no way to change itself. It is a set of instructions for drawing a picture, not a program.
To make that button actually mark you present, something else needs to sit between the click and the paragraph — something that can notice the click happened, decide what to do about it, and reach into the page to change the paragraph's text. That "something" is JavaScript, and the part of the page it reaches into is called the DOM — the Document Object Model. This chapter is about exactly that: how JavaScript gets hold of a live, changeable version of your HTML page, and uses it to make pages that actually respond to what the user does.
The DOM: Your HTML Turned Into a Tree You Can Touch
Here is the key idea, and it is worth sitting with before we write any code. When your browser loads an HTML file, it does not keep that file as plain text forever. It reads the text once and builds a structure in memory out of it — a structure made of boxes connected to other boxes, the way a family tree connects a grandparent to parents to children. That in-memory structure is the DOM. Your original HTML file is just the blueprint; the DOM is the actual building the browser constructs from it, and — crucially — a building you are allowed to walk into and rearrange.
Take this small page:
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Attendance</h1>
<p>Welcome!</p>
</body>
</html>The browser turns this into a tree of connected objects — not lines of text anymore, but actual JavaScript objects sitting in memory, each one knowing who its parent is and who its children are. The whole tree starts from one object called document, which is JavaScript's handle on the entire page.
Notice two kinds of boxes in that tree. Solid boxes are element nodes — things like h1 and p that came from HTML tags. Dashed boxes are text nodes — the actual words sitting inside an element. This distinction matters later: when you ask JavaScript to change "the text inside a paragraph," you are really asking it to replace that dashed box, not the solid one. Every element on your page — the button, the heading, the paragraph — exists as one of these boxes, reachable from document by walking down through parents and children. JavaScript's whole job in this chapter is to grab a box and either read what's inside it or replace what's inside it.
Grabbing a Box: getElementById and querySelector
Before you can change anything, JavaScript needs a reference to the exact box in the tree you want. The two most common tools for this are document.getElementById and document.querySelector.
<h1 id="main-heading">Attendance</h1>
<p class="note">Class VIII - B</p>
<script>
const heading = document.getElementById("main-heading");
console.log(heading.textContent); // Attendance
const note = document.querySelector(".note");
console.log(note.textContent); // Class VIII - B
</script>getElementById takes a plain id (no #) and returns exactly one element, because ids are supposed to be unique on a page. querySelector is more flexible — it accepts any CSS selector, the same kind you use in stylesheets. document.querySelector("#main-heading") would find the same heading by id, document.querySelector(".note") finds the first element with class note, and document.querySelector("p") finds the first paragraph anywhere on the page. If you need every matching element rather than just the first, document.querySelectorAll("p") gives you back a list of all of them, which you can loop over.
Once you hold that reference in a variable — heading, note — you are not holding a copy or a snapshot. You are holding a live connection to that exact box in the tree. Change something through that variable, and the actual page updates immediately, because there is no "page" separate from the tree; the tree is what the browser is drawing.
Changing What's Inside: textContent and the innerHTML Trap
The simplest change you can make is to replace an element's text. The property for this is textContent.
const status = document.getElementById("status");
status.textContent = "Status: Present";This finds the dashed text-node box inside the paragraph and swaps it out for a new one, instantly, with no page reload. There is a second property, innerHTML, that looks similar but behaves very differently, and mixing the two up is one of the most common mistakes beginners make.
const msg = document.getElementById("message");
msg.textContent = "<b>Great job!</b>";
// The browser shows the literal characters:
// <b>Great job!</b>
msg.innerHTML = "<b>Great job!</b>";
// The browser parses the <b> tag as real HTML and shows:
// Great job! (in bold)Misconception to fix now: many students assume textContent and innerHTML are just two names for the same thing. They are not. textContent always treats whatever you give it as plain, literal text — even if that text contains angle brackets, it will show those angle brackets on screen rather than acting on them. innerHTML re-parses its string as actual HTML markup, so any tags inside it get built into new elements. This is why innerHTML is more powerful (you can insert whole chunks of formatted markup at once) but also riskier — if that string ever came from something a user typed rather than something you wrote yourself, innerHTML would let their tags run on your page too. For plain text updates, prefer textContent; reach for innerHTML only when you deliberately want to insert markup.
Worked Example: A Cricket Run Counter
Let's build something that actually reacts to clicks — a simple run counter, the kind of thing you'd use to keep score in a gully cricket match without a scorebook.
<button id="incrementBtn">Add Run</button>
<p>Runs scored: <span id="runCount">0</span></p>
<script>
let runs = 0;
const runSpan = document.getElementById("runCount");
const btn = document.getElementById("incrementBtn");
btn.addEventListener("click", function () {
runs = runs + 1;
runSpan.textContent = runs;
});
</script>Let's trace this line by line, because tracing is exactly how you should read any DOM code before trusting it. First, three things happen once, when the page loads: runs is created in JavaScript's memory and set to 0; runSpan becomes a live reference to the <span> box; btn becomes a live reference to the button box. Nothing on screen has changed yet — the page still shows "Runs scored: 0" exactly as the HTML wrote it.
The call btn.addEventListener("click", function() {...}) does something subtle but important: it does not run the function now. It registers the function with the browser and says, in effect, "keep this function ready, and run it every time this exact button is clicked." The browser then sits and waits — this is called an event, and this whole style of programming is called event-driven, because the code doesn't run top to bottom like a recipe; it runs in response to things happening.
Click #1: runs is 0 before -> runs = runs + 1 -> runs is 1 after -> span shows "1"
Click #2: runs is 1 before -> runs = runs + 1 -> runs is 2 after -> span shows "2"
Click #3: runs is 2 before -> runs = runs + 1 -> runs is 3 after -> span shows "3"Every click re-runs the same two lines inside the function: increase the JavaScript variable runs by one, then push that new number into the span's textContent. The variable runs and the on-screen number are two separate things that we are keeping in sync by hand — the variable is the "true" score living in memory, and textContent is just a snapshot of it that we choose to display. If you forgot the second line, runs would still climb correctly in memory on every click, but the number on screen would stay stuck at 0 forever, because nothing was telling the DOM about the change.
Changing Appearance: style and classList
Text isn't the only thing you can change. Every element also has a style property for direct changes, and a classList for switching CSS classes on and off.
const btn = document.getElementById("incrementBtn");
btn.style.backgroundColor = "#16a34a";
btn.style.color = "white";Notice backgroundColor, not background-color. CSS property names with hyphens become "camelCase" in JavaScript, because a hyphen would otherwise be read as subtraction. This one detail trips up a lot of beginners the first time they try to set font-size and get an error — it has to be written fontSize.
Setting individual style properties from JavaScript works, but it gets messy fast if you want to change several properties together, or the same style in several places. The cleaner approach is to write the styling once in CSS as a class, and use JavaScript only to add or remove that class:
<style>
.highlight { background-color: #fef08a; font-weight: bold; }
</style>
<p id="scoreCard">Runs: 45</p>
<script>
const card = document.getElementById("scoreCard");
card.classList.add("highlight"); // turns highlighting on
card.classList.remove("highlight"); // turns it off
card.classList.toggle("highlight"); // flips it: on if it was off, off if it was on
</script>classList.toggle is especially useful for things like "highlight this row when clicked, un-highlight it if clicked again" — a single line handles both directions without you needing to track the current state yourself.
Creating New Elements: A Growing To-Do List
So far we've only changed elements that already existed in the HTML. The DOM also lets JavaScript build entirely new elements and insert them into the tree — this is how a to-do list app adds new items, or how a chat app adds new messages, without ever reloading the page.
<ul id="taskList">
<li>Maths homework</li>
</ul>
<input id="taskInput" type="text" ="New task">
<button id="addBtn">Add Task</button>
<script>
const addBtn = document.getElementById("addBtn");
const taskInput = document.getElementById("taskInput");
const taskList = document.getElementById("taskList");
addBtn.addEventListener("click", function () {
const taskText = taskInput.value;
const newItem = document.createElement("li");
newItem.textContent = taskText;
taskList.appendChild(newItem);
taskInput.value = "";
});
</script>Trace it: when "Add Task" is clicked, taskInput.value reads whatever the student currently typed into the box — value, not textContent, because an <input> holds its text in a special value property, not as a child text node. document.createElement("li") builds a brand-new <li> box that exists only in memory so far — it is not attached to the tree, and nothing on screen changes yet. Setting its textContent fills that new box with the typed words. The line that actually makes it visible is taskList.appendChild(newItem), which attaches the new box as the last child of the <ul> — only now does the browser draw it. Finally, taskInput.value = "" clears the input box so the student can type the next task. Skip the appendChild step and everything else still runs without error, but the new item is built and simply never shown, because it was never connected to the tree that document is rooted in.
You can trigger the same handler from a keyboard event too, which is what most real to-do apps do so you don't have to reach for the mouse:
taskInput.addEventListener("keyup", function (event) {
if (event.key === "Enter") {
addBtn.click();
}
});Here the browser passes an event object into the function automatically, and event.key tells you exactly which key was released. Checking event.key === "Enter" and then calling addBtn.click() is a neat trick: it programmatically fires the button's own click handler, so you don't have to duplicate the add-task logic in two places.
Misconception: Does Changing the DOM Rewrite the HTML File?
Here is a confusion worth clearing up directly, because it comes up constantly and is genuinely tested in board-style questions about the DOM. When your JavaScript runs status.textContent = "Present", does it edit the .html file sitting on the server or on your computer?
No. It never touches the file at all. The DOM is a structure the browser builds fresh, in the computer's memory, every single time it loads the page. JavaScript changes that in-memory structure, and the browser redraws the screen to match it — but the original file on disk is completely untouched. Proof of this is one keystroke away: if you press Ctrl+U (or right-click → "View Page Source") after clicking that "Mark Present" button, you will see the original, unmodified HTML — still saying "Status: Not marked" — because View Source reads the raw file, not the live tree. Refresh the page, and every DOM change you made vanishes, because the browser throws away the old tree and builds a brand new one from that same untouched file. If you instead open the browser's Developer Tools and look at the "Elements" panel, you will see the live, current DOM — including your change — because that panel reads the actual in-memory tree, not the file. Two different views of "the HTML," two different answers, and knowing which one you're looking at is exactly the skill this misconception check is testing.
Check Your Understanding
Work through these without running the code first — trace them the way we did above, then check your reasoning by actually running them.
- A page has
<p id="score">0</p>. After runningdocument.getElementById("score").textContent = 10 + 5;, what exact text does the paragraph show, and why is it not"10 + 5"? - What is the difference between what appears on screen if you set
box.innerHTML = "<i>Note</i>"versusbox.textContent = "<i>Note</i>"? - In the run-counter example, if you deleted the line
runSpan.textContent = runs;but keptruns = runs + 1;, would clicking the button still increase the score? Would the visitor be able to tell? Explain the difference between "the value has changed" and "the screen shows the change." - Why does
document.createElement("li")alone not make anything appear on the page, and which single line in the to-do list example fixes that? - A friend says: "I clicked a button, the paragraph text changed, so the HTML file on the server must have been edited." Using the View Source vs. Developer Tools distinction, explain why your friend is wrong.
Summary
HTML by itself is static — it describes a page once and has no way to react to anything a user does. The browser converts that HTML into the DOM: a tree of connected objects in memory, rooted at document, with element nodes (solid, from tags) and text nodes (their actual words) as children. JavaScript reaches into this tree using getElementById or querySelector to grab a live reference to a specific box, then reads or rewrites it — through textContent for safe plain text, innerHTML when you deliberately want to insert markup, style or classList for appearance, and createElement plus appendChild to build and attach entirely new boxes. None of this ever touches the original HTML file — it only changes the in-memory tree the browser is currently drawing, which is why a page refresh wipes every DOM change clean and starts over. And nothing happens automatically: every change is triggered by an event, registered with addEventListener, that waits for something specific — a click, a key release — before running. Master these few tools, and any HTML page you can write, you can also make interactive.
Think About It
Think about this: How would you explain javascript dom: making web pages come alive to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.
Practice Exercises
Now it is time to practice! Complete these challenges to solidify your understanding:
- Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
- Exercise 2: Find a real-world example where javascript dom: making web pages come alive is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
- Exercise 3: Create a mind-map connecting javascript dom: making web pages come alive to at least 3 other topics you have studied.