In defense of JavaScript oddities

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

or

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 to know and understand 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

Comments

[Basti Ortiz]

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.

[nepeckman]

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.

[Mihail Malo]

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!

[Andrea Chiarelli]

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

[Vladas Saulis]

Having 'typeless' language doesn't mean you should write typeless programs.
Great writing!

[Mihail Malo]

I suggest you change

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

to

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.

[Andrea Chiarelli]

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

[Paulo Renato]

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.

[Andrea Chiarelli]

Glad I made you smile :-)

[Gopikrishnan]

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

[rhymes]

Ahaha this was funny! Thank you!

[Andrea Chiarelli]

Thanks for you feedback!

[Vedran Mandić]

"...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.

[Andrea Chiarelli]

Thanks!

[Guillaume Martigny]

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.

[Andrea Chiarelli]

You are authorized! :D