What you'll be able to do

By the end of this page you should be able to look at a few lines of JavaScript and say “this is one instruction,” leave a comment for your future self, and stay calm when the console turns red. The red text is not a scolding. It is the engine pointing at a line and telling you what it could not do.

If Blog #1 was “how do I even run this,” this post is “what am I looking at, and what do I do when it breaks.”

Who this is for

  • People who can open the console or a tiny HTML file, but freeze when a red error appears
  • Beginners who copy a snippet, change one quote, and then have no idea which line is wrong
  • Anyone who has been deleting comments because they thought comments were “extra code”

You can skip this if you already read stack traces, you know // from real code, and you can tell a SyntaxError from a ReferenceError. Come back when an error still feels like noise.

Previous post: What JavaScript is and how to run it.

What a statement is

A statement is one complete instruction you give JavaScript. The engine reads your file from top to bottom and tries to carry out each instruction in order, the way you would follow a short cooking recipe — not all at once, and not in a random scramble.

Scenario A — one statement in the console. You type:

console.log("hello");

That whole line is one statement. It means “run console.log with this text.” When it finishes, the engine is done with that instruction.

Scenario B — two statements in a file. You save this in a <script> tag:

const city = "Pune";
console.log(city);

The first statement creates a name, city, and stores a value. The second statement prints that value. If you swap the order and log city before you create it, you get an error — not because JavaScript is moody, but because the second instruction ran before the first one existed.

The rule: think in complete instructions, not in “a bunch of words in a box.” If a line does not finish a thought, the engine often cannot start the next thought.

You will see a semicolon ; at the end of many statements. JavaScript can often insert them for you, which is why some examples work without them. For this series, put a semicolon when you copy the examples, and do not stress about the full automatic-semicolon story yet. We will come back to messy edge cases later. The habit that helps today is: one idea per line, so errors point at a real place.

Comments: notes for humans, ignored by the engine

A comment is text you leave in the file that JavaScript does not run. It is for you, a teammate, or your future self at 11 p.m. when you forgot why a line exists.

Scenario A — a short line comment.

// This button changes the paragraph text
const button = document.getElementById("go");

Everything after // on that line is ignored. The next line still runs.

Scenario B — a block comment, or turning code off for a minute.

/*
  Temporary: I am testing without the click handler.
  Uncomment this when the heading looks right.
*/
// button.addEventListener("click", function () {
//   message.textContent = "clicked";
// });

/ ... / can wrap several lines. Putting // in front of a statement is a common way to “switch it off” without deleting it. That is useful when you are hunting a bug and you want to know whether that line was the problem.

When not to comment: do not write // set city to Pune above const city = "Pune". That comment only repeats the code. Comment the why when the why is not obvious — “school computers block Inspect, so we use a file instead” is useful. “this is a const” is not.

HTML has comments too, and they look different: <!-- this is HTML -->. If you paste an HTML comment into JavaScript, you will get a syntax error. Different languages, different comment shapes.

How to read a red error without panicking

Open the console (F12 → Console). A real error usually has three useful parts:

  1. The type — a short name like SyntaxError or ReferenceError
  2. The message — a sentence in English, even if it is stiff English
  3. The place — a file name and a line number, like first.js:4

Scenario A — you typed in the console. The error appears right under the line you just entered. There may be no file name. That is still readable: the engine is talking about that line.

Scenario B — the error comes from your HTML file. Click the file-and-line link if the browser shows one. Chrome will often jump to the Sources panel and highlight the line. If it does not, open your file in the editor and go to that line number yourself. The number is a gift. Use it.

Below the message you may see a stack — a list of functions that were running when things failed. For now, read the top line first. That is usually the statement that actually broke. The lines under it are “how we got here,” which matters more once functions call other functions.

Three errors you will meet in the first week

SyntaxError — the engine could not even read the line

A SyntaxError means the text is not valid JavaScript, so nothing in that script may run. It is like a sentence with a quote that never closes: the reader cannot tell where the sentence ended.

Scenario A — a missing quote.

console.log("hello);

The string starts with " and never finishes. The console will complain about an unterminated string or an unexpected end of input.

Scenario B — a missing parenthesis.

console.log("hello";

console.log( opened a parenthesis that never closed. Fix the shape of the line before you worry about logic. If the file has a SyntaxError at the top, later lines might not run at all, which is why “I changed line 20 but nothing happens” sometimes means line 3 is broken.

ReferenceError — you used a name that does not exist here

A ReferenceError means JavaScript understood the grammar, started running, and then hit a name it does not know in that place.

Scenario A — a typo.

const city = "Pune";
console.log(citi);

citi is not city. The engine does not guess.

Scenario B — you logged before you created the name, or the id never matched. In the HTML file from Blog #1, if the button id is start and your script still asks for go, document.getElementById("go") returns null (meaning “nothing”). The ReferenceError may show up on the next line, when you do button.addEventListener(...) and button is not what you thought — or you get a TypeError instead, which is the next section. Read the line number. It is telling you which name failed.

TypeError — the name exists, but you used it like the wrong kind of thing

A TypeError means “I found this value, and it cannot do what you asked.”

Scenario A — calling something that is not a function.

const city = "Pune";
city();

city is text. Text is not a function, so city() fails.

Scenario B — calling a method on nothing.

const button = document.getElementById("missing");
button.addEventListener("click", function () {});

If there is no element with that id, button is null. null has no addEventListener. The message often says something like “Cannot read properties of null.” That English is stiff, but the meaning is: you thought you had a button, and you had empty air.

The rule after these three: SyntaxError → fix the writing. ReferenceError → fix the name or the order. TypeError → you have a value, but it is the wrong kind of value for that action.

A small practice file

Save this as errors.html, open it, then open the console. Uncomment one broken line at a time by removing the //, refresh, and read the red text. Then put the // back and try the next one.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Reading errors</title>
  </head>
  <body>
    <p id="status">Open the console.</p>
    <script>
      const line = document.getElementById("status");
      line.textContent = "Script started.";

      // 1) SyntaxError: missing quote
      // console.log("broken);

      // 2) ReferenceError: wrong name
      // console.log(missingName);

      // 3) TypeError: null is not a button
      // const missing = document.getElementById("no-such-id");
      // missing.textContent = "this will fail";
    </script>
  </body>
</html>

Do not uncomment all three at once. A SyntaxError can hide the others because the file never starts running.

Mistakes I see a lot

1. Closing the console because red feels like failure. The red line is the lesson. Read the type, the message, and the line number before you change anything else.

2. Fixing a different file than the one the error names. If the console says first.js:7 and you are editing first.html, you are in the wrong place. Match the file name.

3. Treating every error as “JavaScript is broken.” One missing quote is not a broken language. It is a sentence the engine could not parse. Change one thing, refresh, and see whether the error moved. If the line number changes, you are having a conversation with the engine. That is debugging, even at this size.

What to try before the next post

  1. Run a working console.log("ok"); so you remember what success looks like.
  2. Break the quote on purpose, read the SyntaxError, then fix it.
  3. Log a name you never created, read the ReferenceError, then create the name and try again.
  4. Call getElementById with an id that does not exist, read the TypeError, then fix the id.

Next in this series: variables — let, const, and why var still appears, because once you can read errors, the next confusion is how names hold values.

Try this next outside the series

Once the absolute basics feel clear, leave the series for one practical browser step and one simple tool you can use right now.

javascripttutorialsdevelopers