DEV Community

Cover image for In defense of JavaScript oddities

In defense of JavaScript oddities

Andrea Chiarelli on February 04, 2019

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 tim...
Collapse
 
somedood profile image
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.

Collapse
 
nepeckman profile image
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.

Collapse
 
qm3ster profile image
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!

Collapse
 
andychiare profile image
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

Collapse
 
vsaulis profile image
Vladas Saulis

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

Collapse
 
qm3ster profile image
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.

Collapse
 
andychiare profile image
Andrea Chiarelli

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

Collapse
 
exadra37 profile image
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.

Collapse
 
andychiare profile image
Andrea Chiarelli

Glad I made you smile :-)

Collapse
 
hgopi profile image
Gopikrishnan

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

Collapse
 
rhymes profile image
rhymes

Ahaha this was funny! Thank you!

Collapse
 
andychiare profile image
Andrea Chiarelli

Thanks for you feedback!

Collapse
 
vekzdran profile image
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.

Collapse
 
andychiare profile image
Andrea Chiarelli

Thanks!

Collapse
 
gmartigny profile image
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.

Collapse
 
andychiare profile image
Andrea Chiarelli

You are authorized! :D