Cover image for  In defense of JavaScript oddities

In defense of JavaScript oddities

andychiare profile image Andrea Chiarelli ・3 min read

My fellow members! Ladies and gentlemen of the court!
My client has too often unfairly been an object of ridicule and public derision. Too many times developers, especially the developers of other languages, have made fun of him and laughed at him. They insist on considering it, so to speak, weird, bizarre, geeky.

Most of the reasons for these attacks on my client are based on alleged oddities such as

[] == ![]    // -> true


NaN === NaN             // -> false
Math.max()>Math.min()   // -> false

or even

[] == ''   // -> true
[] == 0    // -> true
[''] == '' // -> true
[0] == 0   // -> true
[0] == ''  // -> false
[''] == 0  // -> true

What are we talking about? What are the oddities?

What’s strange about the fact that, if you submit this request to my client

{} + []

he answers with 0? Where’s the oddity?
Perhaps the strangeness is not so much in the answer as in the question. How can you expect, if you ask my client such a shabby question, to get an answer that makes sense?
My client answers 0, but he might as well answer 42. I do not see why a different answer could be considered less strange than this one.
Perhaps he’d be better off doing what others languages do in this situation, that is raising an exception, getting angry and probably insulting their interlocutor?
No, sirs. My client has a sense of humour and has no intention of offending anyone.
He realizes the absurdity of the request and responds in tone, with an answer of the same tenor.

The classic objection, gentlemen of the court, is that not only my client is strange, but he is not even consistent, since to the following request

[] + {}

he does not respond again with 0, but with [object Object].

Even here, where is the strangeness? Who said that the + operation between an array and an object is commutative? No one is surprised that the result of "foo" + "bar" is different from the result of "bar" + "foo". But if my client gives a different answer when you change the order of the operands, then he is strange.

Another objection against my client is that it is not a true OOP language because it has no classes, or rather the classes it has are not real classes.
First: who said that an OOP language must have classes?
Second: OK, my client has been a little ambiguous in supporting the new keyword and the class keyword. But he did it in good faith, to feel equal to the other languages that snubbed him.

I can’t hide the fact that my client is a bit different from the other languages, but not so different as to deserve mockeries and insults.

The truth is that those who accuse my client of strangeness do not know him and do not want to try knowing and understanding him.
They are so used to rigid languages and without the slightest sense of humor (I would dare to say, without a soul) that they mistake jokes with strangeness and inconsistencies.
But if only these gentlemen try to know him better, to enter into intimacy with my client, they would discover that everything has a reason, that probably the issue is not in the answers that my client gives, but in the questions asked by developers.

This post was originally published on my Medium profile

Posted on Feb 4 '19 by:

andychiare profile

Andrea Chiarelli


Software Designer and Technical Author. Current interests: #programming, #agile, #javascript, #web, #developerexperience #developeradvocacy


markdown guide

YES. THIS right here is a post that I completely agree with. I especially like your argument about the evaluation oddities. If a developer asks JavaScript strange questions, that developer has no right to expect reasonable answers. That pretty much sums it up.

That defense, right there, is why JavaScript is not as bad as others may portray it to be. The only possible way that JavaScript can be bad is if the developer himself writes bad JavaScript. That's all there is to it.


I think that on the whole, JavaScript is a decent language. Its certainly not worse than its cousins, Ruby and Python. But I also think that automatic type coercion is a really bad idea. It doesn't give you much, and it leads to a lot of unexpected behavior. While I agree that [] + {} is not a reasonable line to compute, it should be a TypeError. The fact that JavaScript will happily process the request and continue with your program means that any actual errors will appear later, and the offending line is not clear. There have been plenty of times where I accidentally coerced an object to [object Object] and all of those times it was a bug in my code. An error at the source would have saved me a lot of time.


Truly, for example when you index into a hashmap object with another object instead of its property.

const cache = Object.create(null)
const uselessCache = (arg) => {
  const cached = cache[arg.id]
  if (cached) return cached
  return cached[arg/* [object Object] */] = expensive(arg)
const uselessCacheNowWithMoreWastedMemory = (arg) => {
  const cached = cache[arg/* [object Object] */]
  if (cached) return cached
  return cached[arg.id] = expensive(arg)
const actualCollision = (arg) => {
  const cached = cache[arg/* [object Object] */]
  if (cached) return cached
  return cached[arg/* [object Object] */] = expensive(arg)

Next time on Mythbusters: an even bigger waste of memory by passing these objects to an ES6 Map as keys, meaning they themselves cannot be garbage collected and generating infinite duplicate cached values. What fun!


Thanks for your feedback, @nepeckman .
I think that type coercion is due to historic reasons requiring that a browser should not crash (as much as possible) neither during HTML markup interpretation nor during JavaScript code execution


I suggest you change

No one is surprised that the result of foo + bar is different from the result of bar + foo


No one is surprised that the result of 'foo' + 'bar' is different from the result of 'bar' + 'foo'

Yes, it's just one example, but pretty much the most obvious one.


Thanks for the suggestion, @qm3ster .
It was so in the original version... :-)


AMAZING post... You put a smile in my face :) and I am one of the developers not liking JS and this post even givens me more reason for the WHY ;)

But well JS is not alone on that wagon... I started on PHP that have its fair bit to, but with the difference that its core is heading in a better direction now... fixing that old oddities and inconsistencies.

In JS some are being fixed but not on the core of the language :( or am I missing something?

Disclaimer: backend developer here, not doing that much JS.


Ahaha this was funny! Thank you!


This is great. The right answer for all those strange questions.


He realizes the absurdity of the request and responds in tone, with an answer of the same tenor.

I might re-use that line ! Great defense.


"...do not want to try knowing and understanding him." literally the whole point, it's just people trying to cut a corner (in programming lol). Good article, appreciated.


I am trying to understand something here. You list a number of oddities JS has but you are not explaining or defending it in anyway. Instead you say they are perfectly normal. How the hell Nan === Nan is false normal?


See how joker JavaScript is? :-)

Actually, this may seem puzzling, but there is a reason, and you would have found it by following the links to which the article refers.
More specifically, see here.

Anyway, I'm not saying that JavaScript's oddities are perfectly normal (even because I don't know what normality is).
I'm saying that its so called oddities are perfectly in line with its specifications. Just know them.