There is no excuse for ==, it is just a waste of time.

If to leave only one strict operator, then to replace semantics of == with the ===. But it’s hard because of backward compatibilities — we can’t just leave only one equality operator now.

It’s only possible with invention of a new language — this is how CoffeeScript exactly does — it compiles == into the ===.

I agree that it’s good to use only one style in order not to think about all the cases. But with e.g. the same typeof I don’t see any hazard using == comparing with a string.

@xx11

Interestingly these two lines are not equivalent. In the first case a.valueOf() is called, in the second case – a.toString().

Yes, it’s true in your case since you compare different types on left and right hand sides.

But nevertheless, the end result after applying + operator, is the string (according to 11.6.1, step 7), so we compare strings having "" + ... on both sides.

However, yes, it’s a good note that + calls valueOf first (and then, if it returns not a primitive, tries toString) for the variable value; while String applied as a function calls toString directly. I’ll add this note.

Interestingly these two lines are not equivalent. In the first case a.valueOf() is called, in the second case – a.toString().

var obj1 = {
  toString: function() {return ""},
  valueOf: function() {return 1}
};

""+obj1 == true; // true
String(obj1) == false; // also true

It’s correct for Coffee’s semantics. That is, there manual type casting is required. For JS semantics, I use myself often just ==, e.g. with typeof.

Couldn’t that conversion to lead to errors?

Right; that’s why e.g. CoffeeScript translates == directly into ===, avoiding non-strict equality at all.

Typing ‘===’ in case of typeof and ‘string’ type usually means that developer did not understand very well JS and he/she wrote it is this way ‘just to be sure’.

Yes, that’s it; thanks for the test, I corrected the sentence to reflect the things in more accurate way.