Understanding the Best Javascript Meme I've Ever Seen

Understanding the Best Javascript Meme I've Ever Seen

Originally posted on https://yazeedb.com

I unintentionally found this JavaScript meme on Reddit, and it's the best one I've ever seen.

This is a companion discussion topic for the original entry at https://www.freecodecamp.org/news/explaining-the-best-javascript-meme-i-have-ever-seen/
1 Like

Your TL;DR argument is facetious because the meme is using the wrong datatype on the left side (string 0 or “0”) when the implication is that emptiness is being checked (which would be number 0). If you’re a developer and you’re putting in the wrong datatype on the left side (which JavaScript will coerce the right-side to), then you’re doing it wrong to begin with. Putting a === can just make it fail for another wrong reason; because you’re checking datatype when you meant to check equivalency.

Put in the correct left-side datatype and then the right-side value will coerce properly (an empty array will coerce to a number 0 and return true with a double-equals).

To put it into better context, if you run "any non-empty string" === [] it’ll fail the datatype and won’t even check the values… even if you have "whatever" === [1, 2 ,5] it’ll fail the datatype first. So the triple-equals is only useful when the datatype matters AS WELL as the value, not ALL THE TIME.

I’ve absolutely seen code fail improperly because of excessive datatype checks when the values coerced to the same equivalent value as we needed. If you set up your left side datatype properly then you won’t have to worry about the double-edged sword of coercion improper fail vs datatype improper fail, and can just worry about getting the right-side value to the correct datatype WHEN IT MATTERS.

1 Like


“0” == [“length”] is true tho

Thank you! As a fledgling wannabe developer a the age of half-century+ I needed this article. I knew about triple equal, but I stopped trying to remember what the difference is compared to a double equal is except that it protects me from making a mistake I may not realize I’m about to make. Now I understand the entire coercion thang.

I cannot reproduce this and it also doesn’t make sense.

console.log("0" == ["length"]);

This returns true.

IMO it is so simple

If a string or an array are compared to a number with the “==” operator, they are coerced to a number.

Else, they are coerced to a boolean.

Keeping this simple idea in mind, it becomes clear why the comparisons in the article give those apparently confusing results.

I’ve absolutely seen code fail improperly because of excessive datatype checks when the values coerced to the same equivalent value as we needed.

There is not such a thing like excessive datatype check. There is only datatype check and coercion, and you choose to embrace coercion. I can respect that but it’s a wired behavior of javascript if compared to other strictly typed languages, call it a feature but keep in mind that for other programmers is a weird one or even a bug, a missconcept. Anyway don’t get confused == is for checking equivalence and === is for checking equivalence AND datatype. When you write that === is for datatype check you make an incomplete and wrong statement. I prefer to use === and parse when is the case.


Javascript was intended to light and runtime execution. you cannot expect Objective/Strongly typed Language behaviour in each and every programming language you know of,

if you are expecting the same ? it’s not worthy to invent to new Language.

The Gorilla / Banana problem:

“The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.” ~ Joe Armstrong

Classical Inheritance generally lets you inherit only from a single ancestor, forcing you into awkward taxonomies. I say awkward because without fail, every OO design taxonomy I have ever seen in a large application was eventually wrong.

Say you start with two classes: Tool and Weapon . You’ve already screwed up — You can’t make the game “Clue.”

love the pictures, how did you get them or generated them?

Why are you posting this picture? Is there anything weird about that?

Maybe you didn’t understand what I meant by excessive datatype check; it means, checking datatype when it’s not necessary and doing so will result in a fail when the coerced values are the same but the datatypes are different. I’ve had to fix code where people put in unnecessary triple-equals (the data would not have been a result that would have made a datatype check useful) and data was not parsed correctly.

Example: You get an XML file value that is string 0 (“0” or ‘0’) where the left side checks a var that is numeric 0… the parse will return false when the equivalency was true, therefore a false negative.

I’ve also seen instances where coders have if (typeof someVar === 'undefined')… there’s nothing in JavaScript that can confuse string ‘undefined’ with any other datatype (there’s no numeric ‘undefined’ or boolean ‘undefined’ etc), so the third equal sign is completely excessive (datatype check runs every time completely unnecessarily as it’s not capable of getting an opportunity for datatype to not match).

Again, the author’s example is facetious because the meme is using the left side comparator improperly; initializing it with the wrong datatype for the comparison. The left side needs to be the expected datatype, no matter what, not the other way around. Maybe that’s what you’ve misunderstood.