JavaScript Equality - What's the Default Value?

Why This Question Matters

If you've spent any time in a JavaScript codebase, you've probably encountered a bug that felt like a magic trick. You check a variable, it looks "empty," but your if statement doesn't trigger. Or worse, a value you thought was false actually evaluates to true.

The snippet we're looking at hits on one of the most notorious parts of the language: Type Coercion. Specifically, the difference between how JavaScript handles "falsy" values and how it actually compares them using the loose equality operator (==).

Most developers assume that if two things are "falsy," they must be equal. That’s a trap. Understanding this isn't just about passing a technical interview; it's about avoiding those 2:00 AM debugging sessions where you're staring at a boolean that refuses to behave.

Understanding the Code

Let's look at the snippet:

console.log(0 == false);
console.log("" == false);
console.log(null == false);

At first glance, this looks like it should just be true, true, true. After all, 0, an empty string, and null are all "falsy." But JavaScript doesn't just check if a value is falsy when you use ==; it follows a complex set of rules called the Abstract Equality Comparison Algorithm.

Here is what's actually happening under the hood:

1. 0 == false
When JavaScript sees a boolean in a loose comparison, it first converts that boolean to a number. false becomes 0. Now the comparison is 0 == 0, which is true.

2. "" == false
Again, the boolean false is converted to 0. Now JS tries to compare an empty string to a number. It converts the string "" to a number, which also results in 0. We end up with 0 == 0, which is true.

3. null == false
This is where things get weird. You'd think null would be converted to 0 and return true. But null (and undefined) are special. According to the spec, null is only loosely equal to undefined and nothing else. It doesn't get coerced to a number when compared to a boolean. Therefore, null == false is false.

Finding the Correct Answer

Based on that logic, the output is:
- true
- true
- false

If this were a multiple-choice question where Option B represented this specific sequence, that's your winner. The key takeaway is that while null is "falsy" in an if statement, it is not "equal" to false when using the loose equality operator.

Common Mistakes Developers Make

The biggest mistake is conflating falsiness with equality.

In JavaScript, a value is "falsy" if it evaluates to false inside a boolean context (like an if block). The falsy values are: false, 0, -0, 0n, "", null, undefined, and NaN.

However, == doesn't just check for falsiness. It attempts to coerce the types to match. Beginners often assume that because null and false are both in that "falsy list," they are interchangeable. They aren't.

Another common slip-up is forgetting that NaN (Not-a-Number) is the only value in JavaScript that is not equal to itself. NaN == NaN is false. If you're checking for NaN using ==, you're going to have a bad time.

Real-World Usage

In a production environment, you'll rarely see someone write null == false. But you will see the *effects* of this logic everywhere.

Imagine you're fetching a user's age from an API. If the API returns 0 (maybe it's a newborn), and you write:

if (!user.age) { 
  // Handle missing age
}

That block will execute because 0 is falsy. But if you specifically wanted to check if the age was null (meaning the data was missing) vs 0 (meaning the age is actually zero), the loose check fails you.

This is why the industry standard is to almost always use strict equality (===). Strict equality checks both the type and the value.

0 === false // false (Number vs Boolean)
null === false // false (Object vs Boolean)

By using ===, you opt out of the coercion madness and make your code predictable. The only common exception is checking for both null and undefined at once: if (val == null) is a shorthand that catches both, which is one of the few times == is actually useful.

Key Takeaways

- Loose equality (==) is a minefield. It coerces types based on a set of rules that aren't always intuitive.
- Falsy $\neq$ Equal to False. Just because a value behaves like false in an if statement doesn't mean it's equal to the boolean false.
- null and undefined are picky. They only equal each other when using ==.
- Default to ===. Stop the guessing game. Use strict equality to ensure your types are what you expect them to be.