It seems to me that the operators == and === work the same way. For example:

 1 == 1 // true 1 === 1 // true 1 == 2 // false 1 === 2 // false

The operator == shorter and is often found in other programming languages. So why === at all?

  • After reading the answer, a legitimate question arises: why == in general? - VladD
  • 3
    @VladD Yes, I'm curious too. Many JavaScript experts, such as Douglas Crockford, believe that this was a mistake. It seems that the JavaScript designer, like the PHP designers, thought it would be easier for programmers if the language transforms types in an automatic way. And it seems to me on the contrary, that it is necessary to think more about types when they are suddenly transformed. - Peter Olson
  • And this is not exactly a double? - nick_n_a
  • one
    @nick_n_a, this is more of an original :-) - Grundy

1 answer 1

Operators === and !== are strict comparison operators. Therefore, if the operands are of different types, they are not equal. For example:

 1 === "1" // возвращает false 1 !== "1" // возвращает true null === undefined // возвращает false

Operators == and != Are operators of, say, a rough comparison. That is, if the operands are of different types, JavaScript tries to somehow convert them to become comparable. For example:

 1 == "1" // возвращает true 1 != "1" // возвращает false null == undefined // возвращает true

It is interesting to note that unlike === , the == operator is not transitive :

 "0" == 0 // true 0 == "" // true "0" == ""// false

It is not very easy to remember the rules of this rough comparison, and sometimes it happens that it works in unexpected ways. Therefore, I recommend using === instead of == .

Even I do not remember the fine details of the operator == , so let's see in the specification, clause 11.9.3 :

Abstract Equality Comparison Algorithm

Comparing x == y, where x and y are values, returns true or false. This comparison is made as follows:

  1. If Type (x) is the same as Type (y), then
    1. If Type (x) is Undefined, return true.
    2. If Type (x) is Null, return true.
    3. If Type (x) is Number, then
      1. If x is NaN, return false.
      2. If y is NaN, return false.
      3. If x has the same numeric value as y, return true.
      4. If x is +0 and y is −0, return true.
      5. If x is −0 and y is +0, return true.
      6. Return false.
    4. If Type (x) is String, then return true if x and y have exactly the same sequence of characters (of the same length and with the same characters in the corresponding positions). Otherwise, return false.
    5. If Type (x) is Boolean, return true if x and y are both true or false. Otherwise, return false.
    6. Return true if x and y belong to the same object. Otherwise, return false.
  2. If x is null and y is undefined, return true.
  3. If x is undefined and y is null, return true.
  4. If Type (x) is Number and Type (y) is String,
    return the result of the comparison x == ToNumber (y).
  5. If Type (x) is String and Type (y) is Number,
    return the result of the comparison ToNumber (x) == y.
  6. If Type (x) is Boolean, return the result of the comparison ToNumber (x) == y.
  7. If Type (y) is Boolean, return the result of the comparison x == ToNumber (y).
  8. If Type (x) is either String or Number, and Type (y) is Object,
    return the result of the comparison x == ToPrimitive (y).
  9. If Type (x) is Object and Type (y) is either a String or Number,
    return the comparison result ToPrimitive (x) == y.
  10. Return false.
  • one
    But with fanaticism it is not necessary to approach === : for example, in the expression typeof a === typeof b it is quite enough == . And situations in which there is confidence in the type of operands are not so rare. - Regent
  • 3
    @Regent In principle, I agree, I am against fanaticism, although for me it is easier to just use === everywhere than to think every time, "is it enough == ?" - Peter Olson
  • Something in the comparison algorithm for a branch for two objects was lost. - Qwertiy ♦
  • one
    But no, I found it. Clause 1.6. - Qwertiy ♦
  • you have an error in the second example (rough comparison) null === undefined // returns true, the excess is equal to - Jurij Jazdanov