JS Conditional Operators

Why This Question Matters

If you’ve spent any time in JavaScript, you know that the language loves to surprise you. Most of the time, it's helpful. Other times, it's a total headache. This specific puzzle—comparing three numbers in a row—is a classic "gotcha" that trips up everyone from juniors to seasoned devs.

At first glance, 1 < 2 < 3 looks like basic math. In a math class, this is a perfectly valid way to say "2 is between 1 and 3." But JavaScript doesn't think in mathematical ranges; it thinks in operations and types.

Understanding why this happens is the difference between writing code that "just works" and actually knowing how the JavaScript engine evaluates your expressions. It's all about operator precedence and type coercion.

Understanding the Code

Let's look at the snippet:

console.log(1 < 2 < 3)
console.log(3 > 2 > 1)

To understand the output, you have to stop reading the line as a single mathematical statement and start reading it as a sequence of operations. JavaScript evaluates these expressions from left to right.

#### Line 1: 1 < 2 < 3
1. First, the engine evaluates 1 < 2.
2. This is a simple comparison. Is 1 less than 2? Yes. So, this part returns true.
3. Now, the expression becomes true < 3.
4. Here is where the "magic" (and the confusion) happens. You can't logically compare a boolean to a number. To fix this, JavaScript performs type coercion. It converts true into a number so it can complete the comparison.
5. In JavaScript, true becomes 1 and false becomes 0.
6. The expression is now 1 < 3.
7. Since 1 is indeed less than 3, the final result is true.

#### Line 2: 3 > 2 > 1
1. First, it evaluates 3 > 2.
2. Is 3 greater than 2? Yes. This returns true.
3. Now we have true > 1.
4. Again, type coercion kicks in. true is converted to 1.
5. The expression becomes 1 > 1.
6. Is 1 greater than 1? No. The result is false.

Finding the Correct Answer

The output is:
true
false

If you were looking at multiple-choice options, Option B is the winner.

The mistake most people make is assuming JavaScript handles "chained comparisons" the way Python or some other languages do. In those languages, 1 < 2 < 3 is shorthand for (1 < 2) AND (2 < 3). JavaScript doesn't do that. It just keeps crunching the result of the previous operation into the next one.

Common Mistakes Developers Make

The biggest trap here is the assumption of intuition. We see a pattern we recognize from algebra and assume the language implements it the same way.

Another common mistake is forgetting how truthy and falsy values interact with numbers. If you're debugging a complex conditional and you see a boolean being compared to a number, don't assume it's a bug in the logic—it might be JavaScript's coercion engine doing something unexpected behind the scenes.

Also, watch out for NaN. If you try to compare undefined or NaN in a similar chain, you'll get results that are even more baffling because NaN is never equal to, or greater/less than, anything—including itself.

Real-World Usage

You'll rarely see someone write 1 < 2 < 3 in a production codebase because it's ambiguous and dangerous. However, the *concept* of type coercion is everywhere.

For example, if you're handling API responses or form inputs, you might accidentally compare a string to a number:

const age = "25"; 
if (age > 21) { 
  // This works because JS coerces "25" to a number
}

While this specific example works, relying on implicit coercion is a recipe for disaster. It's why most experienced developers use strict equality (===) and explicit conversion (like Number() or parseInt()).

In a real engineering environment, we prioritize predictability over brevity. If you want to check if a number is between two others, write it explicitly:

if (val > 1 && val < 3) {
  // Clear, readable, and no coercion surprises
}

Key Takeaways

- Left-to-Right: JavaScript evaluates these comparisons sequentially.
- Coercion is Key: When a boolean is compared to a number, true becomes 1 and false becomes 0.
- Don't Trust Intuition: Just because it looks like math doesn't mean it behaves like math.
- Be Explicit: Always use logical AND (&&) for range checks to keep your code readable and bug-free.