In other words, throughout your scripts you’ll probably have lines resembling this:

if (x == y) {
// do something here
}

Or, if you’re conforming to best practices, this:

if (x === y) {
// do something here
}

The difference between those two examples is that the second example uses the triple-equals operator, also called “strict equals” or “identically equal”.

JavaScript beginners who try to adhere to best practices may be using triple-equals and not double-equals, but might not fully understand what the difference is or why it’s important to stick to triple-equals.

What’s the Difference?

In a comparison using the double-equals operator, the result will return true if the two things being compared are equal. But there’s one important catch: If the comparison being made is between two different “types” of values, type coercion will occur.

Each JavaScript value belongs to a specific “type”. These types are: Numbers, strings, Booleans, functions, and objects. So if you try comparing (for example) a string with a number, the browser will try to convert the string into a number before doing the comparison. Similarly, if you compare true or false with a number, the true or false value will be converted to 1 or 0, respectively.

This can bring unpredictable results. Here are a few examples:

console.log(99 == "99"); // true
console.log(0 == false); // true

Although this can initially feel like a good thing (because the browser seems to be doing you a favour), it can cause problems. For example:

console.log(' \n\n\n' == 0); // true
console.log(' ' == 0); // true

In light of this, most JavaScript experts recommend always using the triple-equals operator, and never using double-equals.

The triple-equals operator, as you’ve probably figured out by now, never does type coercion. So whenever you use triple-equals, you’re doing an exact comparison of the actual values. You’re ensuring the values are ‘strictly equal’ or ‘identically equal’.

This means that, using triple-equals, all the examples from above will produce the correct results:

26 Responses

One thing you need to look out for: when you retrieve data from a form it’s always a string. So if you ask a visitor to type a number in a text field (or select a number from a select menu) and then compare that value to a number in your programming, the strict equals will be false. You’ll need to manually cast that form value as a number. For example:

var x = document.formName.fieldName.value; // for example then number 9
console.log(x===9); // returns false, because x is a string ‘9’
x = parseInt(x,10); // turn x into an int
console.log(x===9); // returns true, because x is now an integer

I strongly disagree with the triple equal diktat.
Both have their uses, and if you know JavaScript, using both will never ever be a problem.
Please JS developers, stop supporting JSLint stupid and narrow vision of JavaScript.

I agree with the other commenter saying both have it’s uses. If they didn’t, there would only be one way of checking equality of variables, not two.

I recommend “horses for courses”. Use the equality operator you need for the purpose you need to use it for. For example, there are times when you want 0 to equal to false. If you use 0===false, you will never get true. While 0==false is true. See what I mean?

The only thing I would say to that is that, from a strictly JS perspective, 0 is not equal to “false”, so there should be no reason for you to want it to be. When you say you want zero to equal false, you’re speaking from a data perspective.

So in that case, I would personally prefer to set up my logic to get the numeric value, then once I have that, I would set the value to “false” if it was 0. Or else run the false logic branch if you find 0. I think this is much easier to maintain/understand. But that’s just my view, other devs may find your suggestion more useful, so I can certainly see where you’re coming from.

In IE9 it seems === seems enforced. At least we ran into a bug on code that worked well in IE7 but failed in IE9 just because we used == for comparison. The exception seen with == IE9 was this: “Can’t execute freed script”. The forums mislead us gallantly for that exception, btw :). A team member luckily was familiar with === and we tried it and our app started working like in IE7. Could not find any “official” doc saying it is enforced in IE9(More tidbits: we have win7 64 bit+IE9 running in IE7 compat mode and moved from win XP+IE7)

Leave a Reply

Comment Rules: Please use a real name or alias. Keywords are not allowed in the "name" field. If you use keywords, your comment will be deleted, or your name will be replaced with the alias from your email address. No foul language, please. Thank you for cooperating.

Instructions for code snippets: Wrap inline code in <code> tags; wrap blocks of code in <pre> and <code> tags. When you want your HTML to display on the page in a code snippet inside of <code> tags, make sure you use &lt; and &gt; instead of < and >, otherwise your code will be eaten by pink unicorns.