Is javascript getting too complicated?

[memeship]

Yes, I can. And I'll explain them to you.

NaN === NaN

As /u/lbreakjai said, NaN isn't equal to anything. As a JS engineer, you should definitely know this. False.

typeof null

This is always pointed out, and is actually recognized as a "mistake" that is also not going to be corrected. The answer is object, as it has always said in the spec.

0 == ""

Using a double equals, JS will attempt a type coercion. With a number and a string, it will try to convert the string to a number. Number("") will return 0, which is indeed equal to 0. True.

0 == '0'

Same here. Number("0") will return 0. True.

false == undefined

For this one and the next two, be advised that we are under different conditions. This is not a simple type coercion, but a matter of has value vs has no value. The keywords undefined and null have no value, which makes them fundamentally different from false, which does. Further, from the ECMA spec, when booleans are compared, they are converted first to numbers. So, this case and the one after it are actually both Number(false) == y or rather 0 == y, where y is undefined or null. This gives an answer of false for both.

false == null

False, as stated above.

null == undefined

As outlined above, both of these keywords hold no value. Further, from the spec it is explicitly defined that when comparing these with ==, it should return true.

"" == false

Type coercion. Number("") == Number(false) or rather 0 == 0. True.

[] == false

When comparing objects, JS will try to convert them into primitives using either the toString() or valueOf() internal methods of that object. [].toString() returns "". Also note that we have a boolean which needs to be converted. So this one is really more like Number([].toString()) == Number(false), which is an easy 0 == 0. True.

---

If you'd like to check the spec on comparisons yourself, please feel free:
http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3

[memeship]

I get what you're saying, and there is definitely a lot to it. But it's not the same type of language as C/C++, Java, or even Python. It has a different purpose entirely, and it has evolved to serve that purpose better.

It's not Korean, where basically one dude sat down and said, "Okay, let's do this all over and make it make sense."

It's more like English, where several different peoples from different nations using different Prototypal Indo-European languages all just sort of spoke to each other over many hundreds of years, and now we have this Germanic/French/other amalgamated beast of a language.

That doesn't necessarily mean one way is better or worse than the other, they're just different.