Using === to compare against "true" makes only sense if the variable can be something other than boolean (undefined, null, string etc). Or if you are programming defensively – by choice or because the codebase is messy.
This accurately describes the majority of JavaScript projects I have worked on.
The last web agency I worked at even had linters checking against '=='.
See this table https://dorey.github.io/JavaScript-Equality-Table/ which displays how unsure you can end up when using '=='.
> Most JavaScript developers (who aren't familiar with JS coercion rules or the difference between == and ===)
It rings strange to me that you would believe that developers who focus on one language ("JavaScript developers") wouldn't know the quirks of that language. Not all JS devs are juniors.
I prefer to follow this rule, "never use == and != unless you need type coercion". You know that your expected results is 'true' then why not test for that only?
A bool can be expected today. But why about 10 years from now? Defensive programming isn't a bad thing. Making assumptions is why we had the Y2K mess.
We're not talking about an unstable API here, we're talking about an operator.
It would be just as unreasonable to "defend" your code against `1 + 1` suddenly returning a boolean rather than a number.
