Values, Types & typeof

"Type" is not a JavaScript invention

A type is simply a category that tells you what kind of thing a piece of data is, and therefore what you're allowed to do with it — you can add two numbers, but adding two booleans (true/false values) doesn't mean the same thing conceptually. Every mainstream programming language needs some notion of type for exactly this reason: without it, the language (or you) would have no way to know whether an operation on a piece of data even makes sense.

What's JavaScript-specific is which types exist, how loosely they're enforced, and what the built-in typeof operator — a small piece of syntax, like + or -, that takes a value and produces a result, in this case a string naming that value's type — will and won't tell you correctly about them.

Seven primitives, one catch-all

JavaScript has exactly seven primitive types. "Primitive" here just means a value the language treats as a single, indivisible piece of data — you can't reach "inside" it to change a piece of it; any change produces a brand-new value instead. The seven are: string (text), number (both whole and decimal numbers), boolean (true/false), undefined and null (two different flavors of "nothing" — Lab 04 is entirely about that distinction), symbol (a guaranteed-unique value, used as a rare kind of identifier), and bigint (whole numbers too large for the regular number type to represent precisely).

Everything else in the language — plain {} objects, arrays, functions, dates, and anything else you can build with new or a literal — falls under one single, broad type: object. That split (the third mental-model diagram above) matters a lot more once we get to how values are copied and compared (Lab 21), but for now it's just the map of what exists.

Why does a typeof operator even need to exist?

In a statically-typed language, the compiler already knows every variable's type before the program ever runs, so it can catch a type mistake ahead of time and refuse to compile. JavaScript has no such compile-time check — a variable's type is only knowable by looking at whatever value it currently holds, while the program is running. That's exactly the gap typeof fills: it's a way for your running code to ask, at that exact moment, "what kind of thing am I holding right now?" and branch accordingly. Without it, code that needs to behave differently for a string versus a number would have no reliable way to tell them apart at all.

function describe(value) {
  if (typeof value === "string") {
    return "a piece of text";
  }
  if (typeof value === "number") {
    return "a number";
  }
  return "something else";
}

What typeof actually checks, and where it's wrong

typeof value reports a string naming the value's type — but it has two long-standing quirks worth knowing up front, not stumbling into later:

1. typeof null returns "object", not "null". This is a bug from the language's original 1995 implementation that was never fixed, because fixing it would break existing code across the web. It does not mean null behaves like an object — trying to read a property off null throws an error immediately.
2. typeof a function returns "function", even though a function is, underneath, an object (something Lab 11 covers directly). It's a convenience label, not evidence of a separate fundamental type.

The practical consequence of quirk #1: a check like typeof x === "object", meant to mean "x is a real object I can use," will also silently match x = null — which is not something you can actually use like an object. The safe version adds an explicit exclusion: typeof x === "object" && x !== null.