DEV Community

Cover image for Javascript Quirks and Oddities Museum: Part I
Donny
Donny

Posted on

Javascript Quirks and Oddities Museum: Part I

Every human language has its quirks. Those of you who have studied any foreign language will attest to that. Even computer languages, despite being carefully designed and thought out, have quirks. The reason is that human language, like French for example, and computer language, like javaScript, are alike in one important way: they both were “designed” and “developed” by humans! Anything designed by the human mind must necessarily have some element of irrationality inherent in it as human beings are, on our deepest level, irrational! As my French teacher used to say, “The French verb is a many-colored thing!” Well, that quote could be applied to javascript to some degree.

So let’s look at some of JavaScript’s oddities and curiosities:

Null is an Object

The definition of “null” is the total absence of meaningful value. If that is the case. Why is it that JavaScript considers “null” to be an object?

 alert(typeof null) //alerts ‘object’

This is an unabashed bug in the JS system. “Null” is actually a primitive value if you look it up in the textbooks. So why do the JavaScript Goddesses not descend down and fix this mess?

Basically, it’s because if it were fixed, it would break existing code. If we go back to the first version of JavaScript we’ll see that it had to do with the way values were stored. A simplified explanation is that “null” was a special value that was stored in a bart in a part of the bit units whose data referenced an object. Even so isn’t this an obvious bug to fix? Basically, remember the inventors of JS did this in 10 days and just did get to it. Then, we can suppose it became too late to fix the problem and not cause a lot of grief as more and more things were written with JavaScript.

But wait, it gets even better!

NaN is a Number

Remember back in the day when you were first learning JS? You’ll remember NaN is Not-A-Number. You’ll get it returned to you if you, for example, 1) try to parse a non-number ( parseInt(“blabla”()), 2) a math operation where the result is not a real number ( Math.sqrt(-1)) and a couple of other cases.

So why is that when we call the “typeof” method on “NaN” we get “number”. Further, why is it that “NaN” is NOT strictly equal to itself?

alert( typeof NaN ) // alerts ‘Number’

alert( NaN === NaN ) // evaluates false

The ECMAScript standard states that Numbers should be IEEE-754 floating point data.* This includes Infinity, -Infinity, and also NaN.

Understanding why the statement “NaN === “NaN” evaluates to false is a little more subtle. First, we have to remember what the strict operator( === ) does. The strict operator compares both type and value.

What is the value of NaN (great interview question, BTW)? Well, NaN doesn’t have a real value. So if you compare it to itself, values cannot be compared and therefore the boolean value has to be “false.”

Last one for today:

An Array with No Keys == False

alert( new Array() == false)  // evaluates true

This is a good one--also quite the famous quirk in JS.

So we’ve made a new, empty array and using the loose equality operator to compare it to the boolean ‘false’. Why is that? An empty array is NOT defined as a falsey value**.

Here’s what happens: Under the hold, JS will coerce the new Array by calling .toString() on it. So what we’ll get is:

“” == false

which evaluates to true. An empty string is in fact a falsy value so the statement is true.

Those are just a few of the curiosities JS presents to make us scratch our heads, vex and for the geek in us--delight us.

Stay tuned for more.

In the meantime,

Keep Coding Out Your Dreams!

Donny

*The IEEE Standard for Floating-Point Arithmetic was established in 1985 and is a technical standard for floating-point arithmetic. Read all about it here

**Falsey values in JS are: 0, null, undefined, false, NaN and the empty string(“”).

Top comments (0)