There is a followup article "Don't Make Javascript Equality Look Worse Than It Is"<p>"These posts are fundamentally right about == being poorly designed... but they make things look worse by failing to organize the table.... What a mess! But most of the mess is because of the order of values in the table. By grouping equal values together, you get something more sensible"<p><a href="http://strilanc.com/visualization/2014/03/27/Better-JS-Equality-Table.html" rel="nofollow">http://strilanc.com/visualization/2014/03/27/Better-JS-Equal...</a>
The rules are fairly simple: <a href="http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3" rel="nofollow">http://www.ecma-international.org/ecma-262/5.1/#sec-11.9.3</a>
I like the end of the article. "Use three equals unless you fully understand the conversions that take place for two-equals."<p>Or better said, "Always use 3 equals unless you have a good reason to use 2."
<p><pre><code> if (2) { console.log('yes') }
> yes
> undefined
if (2==true) { console.log('yes') }
> undefined
</code></pre>
I would have thought these would be the same - what's the difference between being "truthy" in the first case, and being ==true, as in the second?
Most of these scenarios are mitigated by knowing what types of data are coming into your functions. If you're defending against a string being compared to a number, I'd sooner wonder why you don't know whether you have a string or a number in your variable in the first place. What could cause you to attempt to use `[1]`(array containing number 1 as an element) as a boolean? Seems like you should know if a variable contains an array and not true/false, and if you don't then that's a better place to focus your attention.<p>Happy to hear counterexamples though.
This reminds me of Miłosz Kośmider's "Zeros in JavaScript" comparison table: <a href="http://zero.milosz.ca/" rel="nofollow">http://zero.milosz.ca/</a><p>Essentially the same thing, but covers a few more operations.
All dynamically typed languages with implicit coercion will have similar-looking tables:<p>PHP: <a href="http://www.blueshoes.org/en/developer/php_cheat_sheet" rel="nofollow">http://www.blueshoes.org/en/developer/php_cheat_sheet</a><p>Perl: <a href="http://qntm.org/equality" rel="nofollow">http://qntm.org/equality</a><p>Python: <a href="http://i.stack.imgur.com/Ya0Ux.png" rel="nofollow">http://i.stack.imgur.com/Ya0Ux.png</a> (I don't think all the entries are correct)
Object plus object is not a number :)<p><a href="https://www.destroyallsoftware.com/talks/wat" rel="nofollow">https://www.destroyallsoftware.com/talks/wat</a>
Interesting, I didn't know about `[1] == true`, `[0] == false` family of equalities.<p>Edit: it seems more general, `42 == [42]` etc. holds.<p>Edit: more fun<p><pre><code> ([0])==false // true
!([0])==false // true</code></pre>