Does using == in JavaScript ever make sense?

It turns out that jQuery uses the construct

if (someObj == null) {
  // do something
}

extensively, as a shorthand for the equivalent code:

if ((someObj === undefined) || (someObj === null))  {
  // do something
}

This is a consequence of the ECMAScript Language Specification § 11.9.3, The Abstract Equality Comparison Algorithm, which states, among other things, that

1.  If Type(x) is the same as Type(y), then  
    a.  If Type(x) is Undefined, return true.  
    b.  If Type(x) is Null, return true.

and

2.  If x is null and y is undefined, return true.
3.  If x is undefined and y is null, return true.

This particular technique is common enough that JSHint has a flag specifically designed for it.

Checking values for null or undefined is one thing, as has been explained abundantly.

There's another thing, where == shines:

You can define comparison from >= like so (people usually start from > but I find this more elegant):

• a > b <=> a >= b && !(b >= a)
• a == b <=> a >= b && b >= a
• a < b and a <= b are left as an exercise to the reader.

As we know, in JavaScript "3" >= 3 and "3" <= 3, from which you get 3 == "3". You can make a point that it's a horrible idea to allow implementing comparison between strings and numbers by parsing the string. But given that this is the way it works, == is absolutely the correct way to implement that relationship operator.

So the really good thing about == is that it is consistent with all other relationships. To put it differently, if you write this:

function compare(a, b) {
  if (a > b) return 1;
  if (a < b) return -1;
  return 0;
}

You are implicitly using == already.

Now to the quite related question of: Was it a bad choice to implement number and string comparison the way it is implemented? Seen in isolation, it seems a rather stupid thing to do. But in the context of other parts of JavaScript and the DOM, it's relatively pragmatic, considering that:

• attributes are always strings
• keys are always strings (the use case being that you use an Object to have a sparse map from ints to values)
• user input and form control values are always strings (even if the source matches input[type=number])

For a whole number of reasons it made sense to make strings behave like numbers when needed. And assuming that string comparison and string concatenation had different operators (e.g. :: for concating and a method for comparing (where you can use all kinds of parameters regarding case sensitivity and what not)), this would in fact be less of a mess. But this operator overloading is probably in fact where the "Java" in "JavaScript" comes from ;)

Yes, I've run across a use case for it, namely when you're comparing a key with a numerical value:

for (var key in obj) {
    var some_number = foo(key, obj[key]);  // or whatever -- this is just an example
    if (key == some_number) {
        blah();
    }
}

I think it's a lot more natural to perform the comparison as key == some_number rather than as Number(key) === some_number or as key === String(some_number).

I ran across a pretty useful application today. If you want to compare padded numbers, like 01 to normal integers, == works just fine. For example:

'01' == 1 // true
'02' == 1 // false

It saves you removing the 0 and converting to an integer.

I know this is a late answer, but there seems to be some possible confusion about null and undefined, which IMHO is what makes == evil, more so that the lack of transitivity, which is bad enough. Consider:

p1.supervisor = 'Alice';
p2.supervisor = 'None';
p3.supervisor = null;
p4.supervisor = undefined;

What do these mean?

• p1 has a supervisor whose name is "Alice."
• p2 has a supervisor whose name is "None."
• p3 explicitly, unequivocally, does not have a supervisor.
• p4 may or may have a supervisor. We don't know, we don't care, we're not supposed to know (privacy issue?), as in it's none of our business.

When you use == you are conflating null and undefined which is wholly improper. The two terms mean completely different things! Saying that I don't have a supervisor simply because I refused to tell you who my supervisor is is wrong!

I understand there are programmers who don't care about this difference between null and undefined or choose to use these terms differently. And if your world does not use null and undefined correctly, or you wish to give your own interpretation to these terms, so be it. I don't think that's a good idea though.

Now by the way I have no problem with null and undefined both being falsy! It is perfectly okay to say

if (p.supervisor) { ... }

and then null and undefined would cause the code that processes the supervisor to be skipped. That is correct, because we don't know or don't have a supervisor. All good. But the two situations are not equal. This is why == is wrong. Again, things can be falsy and used in a duck typing sense, which is great for dynamic languages. It is proper JavaScript, Pythonic, Rubyish, etc. But again, these things are NOT equal.

And don't get me started on non-transitivity: "0x16" == 10, 10 == "10" but not "10" == "0x16". Yes, JavaScript is weakly types. Yes, it is coercive. But coerciveness should never, ever, apply to equality.

By the way, Crockford does have strong opinions. But you know what? He is correct here!

FWIW I understand that there are, and I have personally run into, situations where == is convenient! Like taking string input for numbers and, say, comparing to 0. However, this is hack. You have convenience as a tradeoff for an inaccurate model of the world.

TL;DR: falsiness is a great concept. It should not extend to equality.