== vs ===
7 June 2017
This distinction becomes even more important in the realm of false values. In each of the cases below == evaluates to true, whereas === evaluates to false:
Clearly there are a few times when == is the operator one wants to use, and there are also significantly more times when === is the operator one wants to use. But the overwhelming majority of equality checks don't fall into either category. Most equality checks are something like
Reasons to prefer ===
Since the == is casting the value before checking, it's logical to assume that it is slower to evaluate than the stricter ===. This is a commonly raised argument, though it is contradicted by all available data which shows no performance difference between the two.
Reasons to prefer ==
By consistently preferring ==, that means that encountering a === sets off alarm bells. There are some strange values at play (often null or undefined) that are being considered. For example
Boxed values are a pain in the neck with strict equality.
A fringe benefit is that '==' is one byte shorter than '==='. At scale this adds up to terabytes of saved bandwidth and hours of reduced waiting.
There is no right or wrong choice on this matter. Being consistent with the code around you is probably the most important factor to consider. For me personally, after more than ten years of using == at Google, I've never stumbled into one of the negative Wat cases. Quite the contrary, I'm routinely helped by the comparative rarity of === and its implied warning that something strange is happening with types.