The answer to the question is rather uninformed and borders on wrong, though: > > I oftentimes wonder why JavaScript doesn't have a ".equal()" method like Java

The answer to the question is rather uninformed and borders on wrong, though: > > I oftentimes wonder why JavaScript doesn't have a ".equal()" method like Java and other languages. > Because it doesn't need one :-) Python has none either, btw - for slightly different reasons though. No rationale is given for the assertion that JS doesn't need another way to compare for equality, or what the slightly different reasons are for Python to have no method named `equals()`. Going more into depth, I want to suggest the following: * to have methods `x.equals()` for all `x`es of any type sounds wrong. A facility to compare for equality should exist on the language level, not on the instance/class level. That `equals( 1, 2 )` and `equals( 1, [] )` should both evaluate to `false` is a deep truth about the inner logic of the PL (here: JS) and, more generally, about equality theory; numbers and lists are incidental here. Java got this wrong, Python got it right with its `==` operator. * JS got it wrong from the outset, and Brendan Eich knew this from almost right off the bat. Unfortunately, within months of the first version of JS, Netscape and Microsoft had a get-together with Ecma, and Microsoft opposed Eich's proposal to change the wild and weird behavior of the `==` operator. Eich then suggested to add `===` to the language which is what we're stuck with now. Both operators have an unfortunate choice of symbolics though, because they're really about value identity rather than equality. Too many people are fooled by this, and subsequently weird language and weird APIs cam from this, with nonsense à la 'deep equality'. There's no 'deep equal', there's identity, there's equality, and then there are many application-specific forms of equivalence. Roughly, identity is when two (references to) values are stored in the same memory location and, when mutable, mutations in the one reference is indistinguishable from the same mutations in the other reference. In JS there are no object IDs but one can conceptually think of all primitive values to be interned, IOW whenever you have a `567` or a `'helo'` in one part of your program and a `567` or a `'helo'` in another part of your program, then those always refer to the respectively identical memory locations. Hence, you can use value identity as a sufficient but not necessary condition for equality (in JS, not in Python, although it 'tends to work' there, too). * Contrary to what the reply suggests, JS is in dire need for a way to do sane equality comparisons. It does not have any outside of libraries, and those are often horrible. Here's CommonJS' `assert` API: you get methods named `equal()`, `strictEqual()`, `deepEqual()`, and `deepStrictEqual()`. `equal()` does not test for equality, it tests for 'shallow equivalence', whatever that may be. `strictEqual()` does the same but uses the `===` operator. `deepEqual()` and `deepStrictEqual()` do the same but recursively descend into list elements and object properties. Of these, only `deepStrictEqual()` can be considered to tests for something like equality; the others all do mostly irrelevant equivalence testing, i.e. `assert` has four misleadingly named methods where it should arguably have a single well-named one, `equals()`. * No discussion of the concept of equality in JS or other languages is complete without going into the edge cases: should `NaN` equal `NaN`? should `+0` equal `-0`? should key ordering be considered when comparing objects? And so on. My hunch is there should be a standard answer for all such fringe case, plus a way to generate a new version of an `equals()` function that treats each edge case in a configurable way.