I'm learning JavaScript. A few weeks in, I ran this line:
console.log(typeof null); // "object"
And I stared at it for a while.
null is not an object. It's the value you use to say there is deliberately nothing here. It's a primitive — same family as string, number, boolean. So why does JavaScript insist on calling it an object?
I assumed I'd misunderstood something. I hadn't. It's a bug. It's been in the language since 1995, everybody knows about it, and it is never getting fixed.
Here's the story, because it turned out to be the most interesting thing I've learned so far.
Where it came from
JavaScript was created by Brendan Eich in about 10 days in 1995. That's not a joke — Netscape wanted a scripting language for their browser and they wanted it immediately.
When you build a language that fast, you take shortcuts. One of them was how values got stored in memory. Every value carried a small type tag — a few bits at the front saying "this is a number," "this is a string," and so on. To find out a value's type, the engine just looked at the tag.
The tag for an object was all zeros.
And null? In that original implementation, null was represented as a null pointer — which, on the machine, is also all zeros.
So when typeof looked at null, it saw all zeros, checked its table, and confidently reported: object.
That's it. That's the whole bug. Two different things happened to look identical to the one piece of code that was supposed to tell them apart.
Why it was never fixed
This is the part I find genuinely interesting.
Everyone figured this out pretty quickly. It's not a mystery, and it's not hard to fix — you'd just special-case null in typeof and be done in an afternoon.
But by the time anyone got around to it, the web already existed. Thousands of sites had shipped code that ran typeof x === "object" and depended on getting true back for null. Some of that code was checking whether a value was "object-ish." Some of it was doing something weirder. Nobody knew exactly how much of it was out there, and nobody could go and edit it.
So fixing the bug would mean breaking working websites. Real ones. Pages that people were using.
There was actually a proposal, years later, to make typeof null return "null". It was rejected. The reasoning was blunt: it would break too much.
The bug stayed. Not because it was hard to fix, but because the cost of fixing it was higher than the cost of living with it.
What I actually took away from this
I started out thinking this was a piece of JavaScript trivia — the kind of thing that shows up in interview questions and nowhere else.
But it taught me something bigger, and it's not really about JavaScript:
Once people depend on your mistake, it stops being a mistake and becomes a feature you have to support.
That's a slightly uncomfortable thought when you're a beginner writing code nobody else will ever run. But it reframed how I read old, weird, "why is it like this" corners of a language. Usually the answer isn't that the designers were careless. It's that they were fast, or early, or working with constraints that no longer exist — and then the world built on top of them before anyone could go back.
Ten days in 1995. One shortcut. And typeof null === "object" ever since.
The practical bit
If you actually need to check for null, don't use typeof. Just compare directly:
if (value === null) {
// definitely null
}
And if you want to know whether something is a real object, you have to rule null out yourself:
if (typeof value === "object" && value !== null) {
// an actual object
}
That extra value !== null is in a lot of real codebases. Now you know why it's there.
Have you ever come across a JavaScript behavior that made you stop and think, "Why does it work like that?" I'd love to hear about it in the comments.
Top comments (0)