[mcphage]

The author's primary motivating example is the high cost of deep equality checks. I'm not sure how immutability helps with that; yes, if two variables are === then they havn't changed, but two objects can be !== but still value equal. So if you want to know if two objects are (value) equal, you'll still need to check.

[baddox]

The primary use case for checking equality in React is when you change one part of your application state and it triggers a rerender of a large React component tree. Since you probably only changed one small bit of the state (e.g. you created a new todo list item), you don't actually need to rerender unrelated components (e.g. the already-existing todo list items). Immutable data allows you to do cheap (constant time) reference equality checks, because the data objects representing the existing todo list items will be the exact same objects that they were previously.

In this fundamental React render flow, you probably won't need to worry about checking value equality between two different objects if you are using immutable data. Now, your application might have specific UI requirements that need to do value equality. As a random example, you might have a complex form, and you might want to know if, after the user changed several things, the form's data is different than it was at the beginning. In this case, you'll have to do a (more expensive) value equality check.

[danmaz74]

With React, the point is that by simply comparing the reference to immutable objects you can skip most unnecessary re-renders almost for free. Of course you'll still have some false positives (ie, the reference is different but the content is the same, and re-rendering wasn't necessary) but that's not a big penalty.