I see a lot of comments here suggesting that == is okay to use if you know what you're doing or if the types on both sides match or if this or if that. Writing idiomatic code is all about being expressive and being explicit. Even in the most common case, testing for null or undefined, it's absolutely not clear what is actually happening or what the intent is. I write a lot of JS, and I've never had any justifiable reason to use ==.
The problem with this and the wat talk is that<p>* you don't actually see the case-space (value space) of all the comparisons that <i>do</i> work as expected, and<p>* you don't a sense of what is the likelihood that these sort of comparisons would happen in real world code<p>Some of them like the empty string are likely to happen from user input, but Typescript mitigates those by forcing you to e.g. use Number(inputField.value) to conver to number and complaining about the assignment otherwise.<p>Others pretty much never ever happen - instead of comparing 1 or -1 to true, you're more likely to use if (val) which casts to boolean, and the truthy table is different from the equality comparison table (it makes a bit more sense)<p>Most of the real world comparisons are to non-empty strings or numbers, and those are only equal to arrays in some cases - but its rare for an actual array to be produced by anything. Things you know are arrays already you don't compare using "==" to begin with.<p>So yeah, in practice the confusing rules of JS equality comparison don't really matter all that much.
Fun game. Really captures the spirit of the subject. Great idea!!<p>I’m not one to pride myself on ignorance, but the JS equality operator is ridiculous and therefore, IMO, not worthy of the mental energy it demands.<p>> How well do you know the rules for the == operator in JavaScript?<p>Well enough to use `===`. I’ve noticed in my code every time I’m tempted to use `==`, I always end up finding a better way. `==` is basically code smell that only really smart people should use.
Super cool application, and can teach a lot about why you should use === instead of == in JavaScript.<p>The only legit case to use == is if you are<p>1. Insane<p>2. The kind of person who changes Java 1 object to equal 2
I don't think it is useful to know the behaviour of JS in such cases. In practice, you rarely compare strings with numbers, or objects with booleans.<p>I wrote tens of thousands of lines of JS (e.g. this library <a href="https://github.com/photopea/UPNG.js" rel="nofollow">https://github.com/photopea/UPNG.js</a> ), I never used "===" in my life :D
There's a lot of ===ers in here. I can't say I've ever experienced a situation where not using === has caused an issue. However, I can think of many cases where === would have caused an issue. In other words, I've found == better handles unintended logical errors. Nonetheless, the equality chart is difficult to memorize. Luckily, I typically only deal with a subset of it.
it seems equality operator in javascript is good for nothing but being a source of confusion and a target of jokes.<p>does it not make sense to just remove it from the language completely? who is deciding that?