Equals vs Strictly Equals (== vs ===)

Pop Quiz:

alert(2 == '2');   // true or false?
If you answered false, well… sorry. You'd be wrong. How about this:
function Steve()
  this.toString = function() { return 'Steve is cool!'; };

var s = new Steve();
alert(s == 'Steve is cool!');   // true or false?

False? Actually, no, it's true.

Kind of puzzling isn't it?

Read on to find out what's going on here.

A lot of programmers don't realize it, but javascript actually provides two different (but similar) operators to test for equality. Those two operators are:

Equals: ==
Strictly Equals: ===

The difference between the two lies in their "strictness" so to speak. The first, Equals, is a value-only comparison. This means that the operands need only have the same value for the statement to return true. The type of operands is not taken into consideration.

The second, Strictly Equals, (sometimes called the Identity operator) is a type and value comparison. For this operator to return true, both the value and the type of the operands must be the same.

Generally speaking, it's usually Stricty Equals that you're probably after. After all, most of us have backgrounds in C++, C#, Java, or some other strongly-typed language in which we're used to comparisons mandating that both type and value be equal, which is why we often expect this kind of behavior. It's worth noting that Strictly Equals has a negative counter part: Strictly Not Equals (denoted by the !== operator).

So how much you actually use Strictly Equals or Strictly Not Equals?

Sometimes, they can be (limitedly) useful in validating function parameters as in the following:

function sayHello(_name, _inSpanish)
  var msg = ";
  if (_inSpanish === true)
    { msg = 'Hola '; }
    { msg = 'Hello '; }

  msg += _name;


In the preceding example, the parameter, _inSpanish must actually be equal to true in both type and value. This means that we've ruled out any values that would normally fall through with the traditional == operator (like any integer value for instance). It's interesting to note that ('true' == true) returns false. This seems contradictory to most of the examples so far, but I guess the "value" of true isn't 'true' even though its string representation is.

What's more is that javascript automatically used the string representation of the Steve object as its "value" in the example that appeared at the beginning of the this blog entry, presumably because it had no other "value" to go on.

A little bit strange I must admit…still not 100% sure I've got my head around that one.

Another case where you might find Strictly Equals useful is in validating that numeric parameters are in fact numeric, without having to use parseInt(..) or isNaN(..).

Take the following function which simply checks to see if the _width and _height parameters passed into the function are equal to the width and height of the <body> element.

function checkSize(_width, _height)
  if (_width === document.body.offsetWidth &&
      _height === document.body.offsetHeight)
    alert('they sure are equal');
    alert('not quite');

In the preceding example, we only want to accept values that are strictly equal to the body's width and height. This rules out any string representations of the body width and/or height that might have the same value as one of the parameters, but which is not of the proper type.

This avoids the need to call parseInt(..) or isNaN(..) which can be expensive. In a sample test, testing for strict equality turned out to be faster than using isNaN(..).

A lots of times though, you probably won't need the strictly equals operator. I find that in most real-world scenerios when I'm programming in javascript, the types of my operands are indeed the same.

But using strictly equals is rarely going to hurt you, and in the case of numeric comparisons, it can sometimes save you the inefficient step of running parseInt(..) and/or isNaN(..) on a value.

My general recommendation is to use it, unless you don't need it (and are sure your won't ever need it) for your particular comparison.

In any case, it's good to understand what it's all about — one more thing to add to your arsenal of javascript knowledge.

Comments welcome.

One thought on “Equals vs Strictly Equals (== vs ===)”

Leave a Reply

Your email address will not be published. Required fields are marked *