…or why you should prefer the
- Play the game
- Discussion about value order
- Weak typing in Wikipedia
- Visual explanation
- Abstract equality comparison rules in ECMA-262
== or loose equality operator (and its counterpart
"5" == 5 implicitly converts (coerces) the string
"5" to a number, so the comparison 'just works'. Without loose equality, the same comparison would need to be expressed as either
Number("5") == 5 or
"5" == String(5), or, at the shortest,
+"5" == 5 to be true.
The general principle behind having implicit type conversion is called weak typing, and it's useful to the degree that it makes code more terse, but the flip side is that the implicit conversion rules are basically guesswork about what the user would expect, and, as such, can guess wrong and lead to unexpected results.
== doesn't check for truthiness or falsiness
Values that convert to either
false are called truthy or falsy; for example,
0 is falsy because
Boolean(0) result in
false. Other examples of falsy values are empty strings,
undefined. Meanwhile, all objects (except
document.all) are truthy, so
!! (array object converted to boolean) results in
One would reasonably expect that being truthy also implies
== true and falsy implies
== false, but that's not the case:
 is truthy, but
 == true is actually false.
== breaks transitivity
Transitivity means that if A equals B and B equals C, then A should equal C, but this is not always true with
==; for example,
'' == 0, and
0 == '0', but
'' != '0'.
=== isn't a panacea for typing issues
Tripple equals or strict equality checking rules are much simpler than
==; objects are compared by identity and primitives by value (roughly speaking), but it's still possible to create subtle type-related error conditions by forgetting to convert the compared values to the same type. For example, the user might compare
"1" === 2, intending to compare numbers, and the resulting
false would suggest that the comparison is working correctly, even though
"2" === 2 would fail.
A language like TypeScript would catch these issues, because static typing follows the fail-fast design principle, while dynamic typing ultimately follows garbage in, garbage out – the responsibility is on the user to make sure that the comparison is sound.
Brendan Eich was asked to add the loose equality checking rules by a coworker in Netscape and considers it a mistake.
The initial reason to make this game was to try out state management with immer-wieder, but it's also to demonstrate that the
== rules are easy to get wrong even if you feel like you're familiar with them. It's in response to claims like this one by the well-known author getify:
The game uses emojis; your system and browser should preferably support color fonts and have an emoji font like EmojiOne or Noto Color Emoji installed for the emojis to display properly. If not, the game will provide fallback SVG images from emojitwo (using emoji-extractor).
npm i npm run build # or: npm run start
Adding a translation