1.7 — Booleans, null & undefined

Three small values, three big jobs. true and false — the boolean pair — will power every decision your programs ever make. And then JavaScript has two different ways of saying “nothing”: undefined and null. Two nothings sounds absurd — until you see that they answer two different questions, and that telling them apart is a daily skill in test automation.

watch it happen

let loggedIn = true;
console.log(10 > 3);
let nickname;
console.log(nickname);
let middleName = null;

Line 1: a boolean in its box. The boolean type has exactly two values in the whole universe — true and false. No “maybe”, no “mostly”. It exists to answer yes/no questions.

under the hood

The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”

The clean mental model: undefined is the machine’s nothing; null is the programmer’s nothing.

undefined shows up uninvited, in a few predictable places. A declared-but-unassigned variable (you just saw it). A function that returns nothing (Phase 3). A missing property, or an off-the-end array position (both Phase 4).

null never appears on its own. If you see null, someone put it there to say “this field is intentionally empty.” That someone is a human — or an API (the way your code asks another program, often a server, for data).

Gotcha! Ask the machine typeof null and it answers… "object". That is flatly wrong — null is its own primitive type. The wrong answer is one of the most famous bugs in computing history. It slipped into the very first JavaScript engine in 1995. By the time anyone could fix it, too many programs depended on it. It will never be fixed. Interviewers adore this question; now you have the story, not just the trivia.

💼 On the job — API responses are full of nulls. "middleName": null means the field exists and is deliberately empty. undefined usually means the field is missing entirely. “Empty on purpose” and “forgot to include it” are different bugs, with different fixes. Your future assertions will distinguish the two constantly.

A preview for lesson 1.9, where you meet JavaScript’s two ways of asking “are these equal?”. The loose way (written ==) considers the two nothings equal: null == undefined is true. The strict way (===) knows better: null === undefined is false.

your turn

✏️ Quick check 1

Type exactly what prints:

let score;
console.log(score);

✏️ Quick check 2

JavaScript has two “nothings.” A profile field the person deliberately left empty should hold which one? Type it.

✏️ Quick check 3

What value does the expression 5 === 4 produce? Type it.

teach it back

🗣️ Now teach it back

Explain to a friend: why does JavaScript have TWO kinds of “nothing”, and how would you decide whether a nothing you found is undefined or null territory?

Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.

a few sentences, minimum — you’ve got this

to remember

boolean = exactly two values, true and false — and every comparison (10 > 3) is a factory that produces one.

undefined = the machine’s nothing: “never set.” It appears by itself, as a signal — you rarely write it.

null = the programmer’s nothing: deliberately stored emptiness. And typeof null === "object" is a famous, permanent 1995 bug — great interview story.

next: 1.8 typeof & dynamic typing →