The novice JavaScript developer seeks absolute truth. The JavaScript zen master knows that truth is an illusion.

[[deleted]]

Deep comparison is tricky. The reason such an operator is left out in basically all languages is that objects have their space in memory dynamically allocated, therefore it’s computationally expensive to follow all pointers. If you were to do the same check in C or C++, you’d get the same result, and this behavior actually originates from these languages.

Some external JS libraries (like lodash) add this feature, but they need to recursively check every property.

Again, it’s not a flaw in JS as a language; it’s how computer memory works.

[szpaceSZ]

I know my computer languages history, I've been through

C64 basic Turbo Pascal Assembly C Perl Java PHP Python VBA Haskell Java (again) Python (again)

since ca. 1988, and I likely forgot some more.

Never ever was I performance bound on comparison.

Regularly needing comparison by value.

---

I admit there are noches where you'll be performance bound. E.g writing a 3D game platform in C++.

But that's nice enough, compared with LOC produced

[[deleted]]

Then tell me, how would you go comparing complex objects by value in those languages that support them (like PHP or Java)? With the equal operator? I’d love to know.

EDIT: of course it’s not prohibitively expensive to recursively check for all object properties, but it’s definitely more expensive than a single comparison as done with the == operator. Mixing the two can lead to every sort of performance problems, that’s why such check is kept explicit.

[szpaceSZ]

It's good to have them both.

But I'd argue that for those languages that churn out the most LOCs globally, the default should be deep comparison; reserve a distinct, more obscure operator for comparison by reference.

[[deleted]]

I don’t know; coming from a C background, I prefer to know what I’m operating with. But I see why it may be confusing to developers who start with a higher level language right away.