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.