JavaScript Nullish Coalescing

Why This Question Matters

If you've spent any time in a JavaScript interview or scrolling through "weird JS" threads on Reddit, you've probably seen snippets that look like they're designed specifically to make you fail. One of the classic head-scratchers is [] == false.

At first glance, it looks like it should be false. After all, an array is an object, and an object is truthy. But JavaScript has this quirky habit of performing "type coercion" when you use the loose equality operator (==). This is where things get messy. Understanding why this evaluates the way it does isn't just about winning a trivia game; it's about understanding how JS handles types under the hood so you don't introduce a subtle bug into your production code.

Understanding the Code

Let's look at the snippet:

console.log([] == false)

To understand why this happens, we have to look at the Abstract Equality Comparison Algorithm. That sounds fancy, but it's basically just a set of rules the JS engine follows when it sees ==.

When you compare two different types (in this case, an Object/Array and a Boolean), JavaScript doesn't just say "they're different" and return false. Instead, it tries to coerce them into a common type—usually a number—before making the comparison.

Here is the step-by-step breakdown of what's actually happening:

1. The Boolean is converted: If one of the operands is a Boolean, JS converts it to a Number. false becomes 0.
Now the expression looks like: [] == 0

2. The Array is converted: Now we have an object (the array) and a number. JS tries to convert the object to a primitive. It does this by calling the internal ToPrimitive method. For an empty array, this results in calling .toString().
[].toString() returns an empty string: "".
Now the expression looks like: "" == 0

3. The String is converted: Finally, we have a string and a number. JS converts the string to a number. An empty string "" converted to a number is 0.
Now the expression is: 0 == 0

4. The Final Result: 0 == 0 is true.

Finding the Correct Answer

The answer is True.

Wait, why did I say Option B? In most multiple-choice versions of this challenge, Option B is true.

If you guessed false, you were likely thinking about truthiness. In a conditional statement, like if ([]), an empty array is truthy. But the == operator doesn't check for truthiness; it follows the coercion rules mentioned above.

If you had used the strict equality operator (===), the result would be false because a reference type (Array) is never strictly equal to a primitive (Boolean).

Common Mistakes Developers Make

The biggest mistake is assuming that == behaves like a simple "is this value truthy?" check. It doesn't.

Another common trap is the "Empty Array Paradox." Beginners often think:
- [] is truthy.
- false is falsy.
- Therefore, truthy == falsy must be false.

But as we saw, the coercion chain transforms both sides into 0. This is why you'll see senior devs practically screaming "Use ===!" whenever they review a junior's PR. Strict equality skips all these weird conversion steps and just checks the type and the value.

Another edge case to watch out for is [1] == 1. This also evaluates to true because [1].toString() is "1", which then coerces to the number 1.

Real-World Usage

You will almost never write [] == false on purpose in a professional codebase. If you do, your teammates will probably ask you why you're trying to break the app.

However, this logic pops up in "leaky" abstractions. Imagine you're receiving data from an API that sometimes returns an empty array and sometimes returns null or false to indicate "no data." If you use a loose check like if (data == false), you might accidentally trigger a logic branch when data is actually an empty array, leading to a UI bug that's incredibly hard to track down.

The professional way to handle this is to be explicit about what you're checking:

// Bad: Ambiguous and relies on coercion
if (data == false) { ... }
// Good: Check for the specific "empty" state you care about

if (Array.isArray(data) && data.length === 0) { ... }

Key Takeaways

- Loose equality (==) is a minefield. It doesn't just check values; it forces types to change until they match.
- The Coercion Chain: Boolean $\rightarrow$ Number $\rightarrow$ String $\rightarrow$ Number.
- Truthiness $\neq$ Equality. An empty array is truthy in an if statement, but it coerces to 0 when compared loosely to a boolean.
- The Solution: Always use === (strict equality). It removes the guesswork and makes your code predictable.