If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Enjoy an ad free experience by logging in. Not a member yet? Register.

It is preferable to avoid using == in JavaScript where possible. === is the better comparison operator to use and should work fine in this instance.

I don't really see why you say that. The Mozilla Development Network says

Use strict equality operators if the operands must be of a specific Type as well as value or if the exact Type of the operands is important. Otherwise, use the standard equality operators, which allow you to compare the identity of two operands even if they are not of the same Type.

I agree with that. Automatic type conversion is one of the advantages of Javascript which ought not to be rejected. Use of strict equality comparisons is often completely unnecessary. Even if you don’t use == in your code someone else will (e.g. jQuery).

The === operator would seem to have little point when comparing strings:-

i agree with 80% of crockford's dogma, but "==" has its place. it's probably better to encourage == so that form values can compare to numbers without the explicit type conversion boilerplate of languages from the 60s...

Automatic type conversion is one of the advantages of Javascript which ought not to be rejected.

It is actually one of the biggest disadvantages that JavaScript has. A significant fraction of errors made by those who are relatively new to JavaScript are caused by the fact that JavaScript is not a strongly typed language. At least that's been my experience wit the sorts of errors I have seen in beginner's code.

I do agree that == has its place but only where you don't know the type of one of the two values being compared and are doing the comparison to work out whether it can be meaningfully converted to a specific type. Where the types of both values is known then specifically converting them to the same type in order to compare them reduces the chances of errors later.

To use your example to illustrate this - given that a and b are variables for a subsequent call to the same comparison they could have different values assigned and then the == might give the wrong result:

Add those two to your original example and you can easily see how == does not always produce the expected result whereas using === and converting to a specific type does give the right result in those instances where == gets it wrong.

Allowing the == to do the conversion can also be confusing - '9'==9 converts the number to a string in JavaScript but in PHP the same comparison converts the string to a number. For someone used to one language learning the other this can lead to subtle differences from the expected result.

Allowing the == to do the conversion can also be confusing - '9'==9 converts the number to a string in JavaScript but in PHP the same comparison converts the string to a number. For someone used to one language learning the other this can lead to subtle differences from the expected result.

what difference does it make how the conditional is internally decoded?

The conditional's true/false result is the same either way under any scenario my feeble mind can imagine.

if you wanted the string to become a number, simply add "+" to the equation: (+'9'==9). this forces a numerical conversion upon the string just before the comparison is assessed.

i think one of the reasons people make mistakes like that in JS is because they used old-fashioned static typed languages first. boo on them. For people who start in JS, i don't see those mistakes happening very often. 1989 was a long time ago, let's all get our mental models caught up to dynamic data representation.

I have to say it does not scare me in the slightest, as it is obvious to me that both are numbers.

I don't see the point of felgall's date comparison example. You cannot compare two date objects. Two objects are strictly equal if (and only if) they refer to the same object. And alert(''+a==''+b) is just as true as alert(''+a===''+b).

rnd me regards static type languages as old-fashioned. I don't have the expertise to comment, but I still think that automatic type conversion is one of the advantages of Javascript which ought not to be rejected.

As usual, let us agree to disagree. To some extent it is a matter of "house style".

Last edited by Philip M; 02-09-2013 at 08:35 AM.

All the code given in this post has been tested and is intended to address the question asked.
Unless stated otherwise it is not just a demonstration.

it's an indisputable fact of history that strong typing came first. Machine languages need to be strong typed, for good reason. At some level, all languages are executed with strong types, even javascript.

The difference is that the machine does the tedious work of type conversion in JS. Compared to older languages like C, C++, or even Java, JS does a lots of tedious work for you: memory management, auto local name closures, semi-colon insertion, automatic function hoisting, etc. If you are awesome, not over-worked and smart, you can probably do a better job yourself. This is not unlike the age-old debate of using jQurey -vs- hand-built code.

as with anything mechanical, trade offs result. A honda civic with a good driver and a stick shift can always undercut the quarter-mile time of the same driver driving a civic with an automatic transmission.

So which car is better?

In this context, i think it's an obvious opinion, and only a fool would claim otherwise.

you might have caught a typo or two earlier with strict types, but with modern IDEs like M$ VS2012 (and many more soon, just wait), you can see those errors as you type, before you even save, much less compile.
plus we have jslint and jshint, in some editors in real-time, to enforce the level of convention and control a project is slated for, including using "==" where "===" would work.

in those respects, weak typing is a new-fashion way of coding with some but increasingly fewer disadvantages to it's predecessors.

Coming from a background of mostly web development, I was a fan of weak-typed languages for a long time. Eversince I started getting more and more into, for example, Java, I like strong-typed languages better. It just feels cleaner to work with correct types and not compare apples and oran… I mean numbers and strings. And even weak-typed languages usually allow you to work with types – they also just allow you to be lazy. And these days I just try to get rid of laziness in programming as much as possible.

@ Old Pedant (yes, some people can get your name right )

The "problem" I have with that example is that integers and floating points are different objects in languages like the C family etc., but they are not in JavaScript – they both are of the type "Number" and therefore equal.
However, the same argument can't be used for strings and numbers. "5" == 5 might still be true, but "5" and 5 are not of the same type (String <-> Number). JavaScript just allows the type-insensitive comparison, but they are not the same objects.

All in all: I personally prefer using === whenever I can. I also check types. Currently I'm working with qooxdoo, which even automatically checks for types and makes JavaScript much stricter – and I like it.

BUT:

But let's forget about personal preferences. What about == versus === in pure terms of performance? Well, I prepared a little test: http://jsperf.com/the-truth-about-comparisons
It tests all combinations of types and result for both == and ===. What's the result?

Well: As long as types are equal, == and === don't make much of a difference. Actually, === may even be slightly slower. But that's the point: slightly slower and only maybe. Doesn't really surprise, does it?
But this wasn't the point, because people argue in favor of == when types are different. For different types, the result couldn't be much clearer: === outperforms == by a lot. And that's simply because once the types are checked to be different, actually checking the value becomes unnecessary.

So whenever you need to care about performance (i.e. loops), === should be the way to go. As for ==, there is no real argument in favor of it except that you can be lazy not to care about the types, which will save you some code.

To summarize it with a personal note again: Laziness should never ever be a justification for your code. Also, performance is always an issue on the web, especially if mobile development is involved.

If you look at the results, === performs about ten times faster than == when types are different.

That's not as much as, for example, the complexity of different sorting algorithms where you go from O(n²) to O(n * log n), but a factor of ten is a huge improvement. And it's as cheap as one additional "=".

Maybe the main argument against my test is now going to be that "5"==5 is true and "5"===5 isn't, so they produce different results which may not be wanted. And that means you'd need to convert before using ===. Which will slow it down again.

However, the following test shows that even if you only compare once, conversion + === is still faster than ==. Using more than one comparison, the initial conversion will outperform == even more: http://jsperf.com/versus-conversion