A Language in a Hurry
To understand the most peculiar feature of JavaScript, you have to go back to 1995. The internet was a digital wild west, and Netscape Navigator was the browser king. But a shadow loomed: Microsoft. To compete, Netscape decided it needed to make web pages more dynamic. The company hired developer Brendan Eich with a mission that sounded impossible: create a new programming language for the browser, and do it before the next major release. Eich was given just ten days in May 1995. This wasn't a thoughtful, academic exercise; it was a desperate, high-stakes sprint. Under immense pressure, he cobbled together a language that mixed features from several others, aiming for something easy enough for designers and amateurs to use. He called it Mocha,
then LiveScript, and it was finally renamed JavaScript in a marketing move to ride the coattails of the then-popular Java. This chaotic birth is the key to everything that followed.
The Bug That Became a Feature
In programming, it's common to check what 'type' of data a variable holds. Is it a number, a string of text, or something else? JavaScript has an operator for this called `typeof`. It’s also common to have a value that represents 'nothing'—a deliberate, intentional emptiness. In JavaScript, this is called `null`. Here’s where the 10-day sprint comes back to haunt us. If you ask JavaScript the type of the value `null`, you’d expect it to say, well, 'null'. Instead, it says 'object'. Try it in any web browser's developer console: `typeof null` returns `'object'`. This was not a grand design choice. It was a simple bug. In the original implementation, values were represented with a type tag and the value itself. For objects, the type tag was `0`. `null`, for historical reasons in C-like languages, was represented as the null pointer, which was also `0`. The `typeof` logic just checked the 'object' type tag and didn't have a separate check for the `null` value, so it mistakenly reported `null` as an object.
The Point of No Return
In a normal software project, a bug like this would be identified and fixed. And in the early days of standardizing JavaScript (under the name ECMAScript), a fix was proposed. But it was already too late. By the late 90s, JavaScript was exploding across the web. Countless scripts had been written by developers who were now, consciously or not, relying on this bug. Some programmers had written code like `if (typeof value === 'object')` to check for both real objects and for `null` values at the same time. Fixing the bug—making `typeof null` return `'null'`—would have broken an untold number of existing websites. The committee in charge of the language, TC39, faced a choice: correct the language's design or preserve the functioning web. They chose the latter. This decision enshrined a core principle of web development: "Don't break the web." The mistake became permanent.
A Fossil in the Code
This single, 'forgotten' decision has had a lasting impact. For over 25 years, every JavaScript developer has had to learn to work around it. The standard way to properly check if something is an object is to first make sure it’s not `null`, leading to slightly more verbose code: `if (variable !== null && typeof variable === 'object')`. Automated code checkers, called linters, are programmed to watch for this exact scenario. More importantly, `typeof null` serves as a permanent fossil embedded in the code, a testament to the trade-offs at the heart of software development. It demonstrates that 'good enough' and 'fast enough' often beat 'perfect'. It's a lesson in technical debt—the long-term cost of short-term compromises. While it may be a minor annoyance in a developer's day-to-day life, it tells a much bigger story about how the web was built: not with pristine architectural blueprints, but with scrappy, pragmatic, and sometimes flawed decisions that we all must live with.
