This suggests that you don't actually know what the === operator is. To summarize:
== - 'values are equal' - in this case, are these two numbers equal? The IEEE spec would say no. I agree!
=== - 'both sides are exactly the same' - or, in more technical terms, are both the values and types of each argument exactly identical. In this case, the answer is yes, absolutely. === is not a numerical comparison and should not be.
=== means value and type are equal. In this case, the types are equal, but the values are not. I'd argue that NaN === NaN being true would imply a broken implementation of IEEE 754, and the designers of JS seem to agree with me.
What benefit is created by having a hierarchy of comparison operators in which there is no actual way to compare two numbers for semantic (not numeric) equivalence?
If (NaN == NaN) == false, and (NaN === NaN) == false, how would you implement an isNaN() function? If your answer is 'depend on the VM', I find that a bit strange.
typeof(NaN) should still be 'number', which would identify it uniquely. The irony of the value "Not a Number" having type "Number" is not lost on me, however.
new String("foo") === new String("foo") is false. === does not mean value and type are equal, it means that the left is the same object as on the right OR that both the left and right are primitives with the same value.
The behavior there is a result of the 'new' operator. typeof new String("foo") is specified to be "object", and it is extensible (String("foo") is not). Both == and === on two object-types return true if both refer to the same thing. More generally, when two types are the same, == has the same behavior as ===.
`===` means that javascript does a normal equality test, whether it be string comparison or numerical comparison, but without any type conversion. It means that while `"3" == 3` is `true` when you execute `"3" === 3"` it is false.
Given two `NaN`s, it would see they're both floats, do a floating point comparison, and return `false`. As it should.
"== - 'values are equal' - in this case, are these two numbers equal? The IEEE spec would say no."
"=== - ...are both the values and types..."
If the values are not equal, how can both the values and types be?
Looking at the ECMAScript 5 standard even if you take out the explicit handling of NaN in the === (Strict Equality) definition it should still evaluate to false since the next subrule compares the numeric value.
4.If Type(x) is Number, then
a.If x is NaN, return false.
b.If y is NaN, return false.
c.If x is the same Number value as y, return true.
== - 'values are equal' - in this case, are these two numbers equal? The IEEE spec would say no. I agree!
=== - 'both sides are exactly the same' - or, in more technical terms, are both the values and types of each argument exactly identical. In this case, the answer is yes, absolutely. === is not a numerical comparison and should not be.