In Defence of ==: The JavaScript Opinion Everyone Hates

As JavaScript developers, we’ve all heard this rule:

Always use strict equality (===). Never use loose equality (==).

And honestly… it’s not bad advice. It’s safe, it prevents bugs, and it avoids surprises.

But have you ever paused and asked:

Why exactly is == considered evil?
Is it truly broken? Or is it just misunderstood?

Because here’s the thing: == isn’t random. It’s not “bad JavaScript”. It’s not a bug.

It follows rules. Very specific rules.

And once you understand those rules, you’ll realize something important:

== isn’t always dangerous.
It’s dangerous only when you don’t understand what it’s doing.

So let’s bust a few myths and learn how == actually works — so you can choose between == and === intentionally instead of blindly following internet rules.

First, Let’s start with what everyone knows:

const a = "1"
const b = 1
console.log(a == b) // True
console.log(a === b) // False

We all know the output — but why does it happen?

What happens with === (strict equality)

Strict equality is simple and predictable, it follows Strict Equality Comparison:

✅ How === works

1. It checks if the two values are the same type

2. If types are different → it immediately returns false

3. If types are the same → it compares values and returns true/false

So for this:

"1" === 1

Types differ (string vs number) → false

No coercion. No conversion. No surprises.

The complete set of rules followed by Strict Equality Comparison as per ECMAScript are:

What happens with == (loose equality)

Loose equality uses something called Abstract Equality Comparison (as per ECMAScript spec).

It tries to answer:

“Can these two values be considered equal after applying JavaScript’s coercion rules?”

✅ How == works (simplified but accurate)

1. If both values are already the same type, it behaves like strict equality.

2. If types are different, JavaScript tries to coerce values so a comparison can happen.

In many cases, JavaScript prefers a numeric comparison, so it converts values to numbers.

So this:

"1" == 1

Becomes:

ToNumber("1") == 1
// 1 == 1
// true

That’s why the output is true.

The complete set of rules followed by Abstract Equality Comparison are:

So, if you really think about it, the == and === both check the types, the difference is what they do with that information.

And here’s a key line from the spec (paraphrased):

If the types are the same, == behaves like strict equality comparison.

This clearly shows that if we are really sure about the types of our variables, we might be good with using ==

Example: when == and === behave identically

const name1 = "John"
const name2 = `${name1}`; // John
console.log( name1 == name2) // true
console.log(name1 === name2) // true

You see, we get the same result in both the cases because Same type (string) → == behaves just like ===.

That means, we might have misunderstood == through the internet.

It’s just that == is more powerful, and with great power comes great responsibility.

Now, You might be thinking, well this is an obvious example and it does not really matter if use == or === in such cases. Then why bother about == altogether?

The real “safe” use case for == (yes, it exists)

Well, let me show you some examples where == can be helpful(yes, they exist) and does exactly what you want it to do.

if(value == null){
 // runs if value is null OR undefined
}

This works because in case of == null is equal to undefined.

But:

• 0 == null → false

• "" == null → false

• false == null → false

So this check is precise and useful.

But in case of ===, this would have looked like:

if( value === null || value === undefined){
}

Both are correct — but the == null version is compact and intentional.

This shows us that == is not always bad, we just have to think and decide whether we want to allow coercion or not.

So, Why == got a bad reputation?

Because coercion can produce results that look insane if you don’t know the rules.

0 == ""        // true
0 == "0"       // true
false == ""    // true
false == "0"   // true

Now, you might think, well I would just use a === instead of taking this mental load. And you are right in thinking so, but its always a good practice to know the types of your variables irrespective of which equality comparison you use, because that way, you avoid the uncertainty in your code.

So… should you use ==?

Here’s the nuanced answer:

Use === by default

It’s predictable and reduces mental load.

Use == intentionally in specific cases

Especially:

• value == null checks

• cases where coercion is explicitly desired and understood

To wrap it up, == isn’t evil — it’s just misunderstood. Loose equality follows a clear set of coercion rules, and once you understand them, it stops being scary and starts being predictable. The real problem isn’t the operator itself, but how often it’s used without awareness. So don’t treat == as a forbidden symbol — treat it as a tool: use === by default, but understand == well enough to know when it’s safe, useful, and even cleaner.

So the next time someone says:

“Never use ==”

You can reply:

“Use === by default. But understand == — because JavaScript already does.”

And honestly… reading the spec once in a while might save us from a lot of myths.

As a final thought, I would leave you to with this one line

“Don’t fear ==. Understand it.”