Why is immutability so important (or needed) in Ja

Question

I am currently working on React JS and React Native frameworks. On the half way road I came across Immutability or the Immutable-JS library, when I was reading about Facebook's Flux and Redux implementation.

The question is, why is immutability so important? What is wrong in mutating objects? Doesn't it make things simple?

Giving an example, let us consider a simple News reader app with the opening screen being a list view of news headlines.

If I set say an array of objects with a value initially I can't manipulate it. That's what immutability principle says, right? (Correct me if I am wrong.) But, what if I have a new News object that has to be updated? In usual case, I could have just added the object to the array. How do I achieve in this case? Delete the store and recreate it? Isn't adding an object to the array a less expensive operation?

PS: If the example is not the right way to explain immutability, please do let me know what's the right practical example.

Answer 1

The question is, why is immutability so important? What is wrong in mutating objects? Doesn't it make things simple?

About mutability

Nothing is wrong in mutability from technical point of view. It is fast, it is re-using the memory. Developers are use to it from the beginning (as I remember it). Problem exists in the use of mutability and troubles which this use can bring.

If object is not shared with anything, for example exists in the scope of the function and is not exposed to the outside, then it is hard to see benefits in immutability. Really in this case it is no sense to be immutable. The sense of immutability starts when something is shared.

Mutability headache

Mutable shared structure can easily create many pitfalls. Any change in any part of the code with access to the reference has impact to other parts with visibility of this reference. Such impact connects all parts together, even when they should not be aware of different modules. Mutation in one function can crash totally different part of the app. Such thing is a bad side effect.

Next often problem with mutation is corrupted state. Corrupted state can happen when mutation procedure fails in the middle, and some fields were modified and some not.

What’s more, with mutation it is hard to track the change. Simple reference check will not show the difference, to know what changed some deep check needs to be done. Also to monitor the change some observable pattern needs to be introduced.

Finally, mutation is reason of the trust deficit. How you can be sure that some structure has wanted value, if it can be mutated.

const car = { brand: 'Ferrari' };
doSomething(car);
console.log(car); // { brand: 'Fiat' }

As above example shows, passing mutable structure always can finish by having different structure. Function doSomething is mutating the attribute given from outside. No trust for the code, you really don't know what you have and what you will have. All these problems take place because: Mutable structures are representing pointers to the memory.

Immutability is about values

Immutability means that change is not done on the same object,structure, but change is represented in new one. And this is because reference represents value not only memory pointer. Every change creates new value and doesn't touch the old one. Such clear rules gives back the trust and code predictability. Functions are safe to use because instead of mutation, they deal with own versions with own values.

Using values instead of memory containers gives certainty that every object represents specific unchangeable value and it is safe to use it.

Immutable structures are representing values.

I am diving even more into the subject in medium article - https://medium.com/@macsikora/the-state-of-immutability-169d2cd11310

Answer 2

A Different Take...

My other answer addresses the question from a very practical standpoint, and I still like it. I've decided to add this as another answer rather than an addendum to that one because it is a boring philosophical rant which hopefully also answers the question, but doesn't really fit with my existing answer.

TL;DR

Even in small projects immutability can be useful, but don't assume that because it exists it's meant for you.

Much, much longer answer

NOTE: for the purpose of this answer I'm using the word 'discipline' to mean self-denial for some benefit.

This is similar in form to another question: "Should I use Typescript? Why are types so important in JavaScript?". It has a similar answer too. Consider the following scenario:

You are the sole author and maintainer of a JavaScript/CSS/HTML codebase of some 5000 lines. Your semi-technical boss reads something about Typescript-as-the-new-hotness and suggests that we may want to move to it but leaves the decision to you. So you read about it, play with it, etc.

So now you have a choice to make, do you move to Typescript?

Typescript has some compelling advantages: intellisense, catching errors early, specifying your APIs upfront, ease of fixing things when refactoring breaks them, fewer tests. Typescript also has some costs: certain very natural and correct JavaScript idioms can be tricky to model in it's not-especially-powerful type system, annotations grow the LoC, time and effort of rewriting existing codebase, extra step in the build pipeline, etc. More fundamentally, it carves out a subset of possible correct JavaScript programs in exchange for the promise that your code is more likely to be correct. It's arbitrarily restrictive. That's the whole point: you impose some discipline that limits you (hopefully from shooting yourself in the foot).

Back to the question, rephrased in the context of the above paragraph: is it worth it?

In the scenario described, I would contend that if you are very familiar with a small-to-middling JS codebase, that the choice to use Typescript is more aesthetic than practical. And that's fine, there's nothing wrong with aesthetics, they just aren't necessarily compelling.

Scenario B:

You change jobs and are now a line-of-business programmer at Foo Corp. You're working with a team of 10 on a 90000 LoC (and counting) JavaScript/HTML/CSS codebase with a fairly complicated build pipeline involving babel, webpack, a suite of polyfills, react with various plugins, a state management system, ~20 third-party libraries, ~10 internal libraries, editor plugins like a linter with rules for in-house style guide, etc. etc.

Back when you were 5k LoC guy/girl, it just didn't matter that much. Even documentation wasn't that big a deal, even coming back to a particular portion of the code after 6 months you could figure it out easily enough. But now discipline isn't just nice but necessary. That discipline may not involve Typescript, but will likely involve some form of static analysis as well as all the other forms of coding discipline (documentation, style guide, build scripts, regression testing, CI). Discipline is no longer a luxury, it is a necessity.

All of this applied to GOTO in 1978: your dinky little blackjack game in C could use GOTOs and spaghetti logic and it just wasn't that big a deal to choose-your-own-adventure your way through it, but as programs got bigger and more ambitious, well, undisciplined use of GOTO could not be sustained. And all of this applies to immutability today.

Just like static types, if you are not working on a large codebase with a team of engineers maintaining/extending it, the choice to use immutability is more aesthetic than practical: it's benefits are still there but may not outweigh the costs yet.

But as with all useful disciplines, there comes a point at which it is no longer optional. If I want to maintain a healthy weight, then discipline involving ice cream may be optional. But if I want to be a competitive athlete, my choice of whether or not to eat ice cream is subsumed by my choice of goals. If you want to change the world with software, immutability might be part of what you need to avoid it collapsing under it's own weight.

Answer 3

The question is, why is immutability so important? What is wrong in mutating objects? Doesn't it make things simple?

Actually, the opposite is true: mutability makes things more complicated, at least in the long run. Yes, it makes your initial coding easier because you can just change things wherever you want, but when your program goes bigger it becomes a problem – if a value changed, what changed it?

When you make everything immutable, it means data can't be changed by surprise any more. You know for certain that if you pass a value into a function, it can't be changed in that function.

Put simply: if you use immutable values, it makes it very easy to reason about your code: everyone gets a unique* copy of your data, so it can't futz with it and break other parts of your code. Imagine how much easier this makes working in a multi-threaded environment!

Note 1: There is a potential performance cost to immutability depending on what you're doing, but things like Immutable.js optimise as best they can.

Note 2: In the unlikely event you weren't sure, Immutable.js and ES6 const mean very different things.

In usual case, I could have just added the object to the array. How do I achieve in this case? Delete the store & recreate it? Isn't adding an object to the array a less expensive operation? PS: If the example is not the right way to explain immutability, please do let me know what's the right practical example.

Yes, your news example is perfectly good, and your reasoning is exactly right: you can't just amend your existing list, so you need to create a new one:

var originalItems = Immutable.List.of(1, 2, 3);
var newItems = originalItems.push(4, 5, 6);

Answer 4

Although the other answers are fine, to address your question about a practical use case (from the comments on the other answers) lets step outside your running code for a minute and look at the ubiquitous answer right under your nose: git. What would happen if every time you pushed a commit you overwrote the data in the repository?

Now we're in to one of the problems that immutable collections face: memory bloat. Git is smart enough to not simply make new copies of files every time you make a change, it simply keeps track of the diffs.

While I don't know much about the inner workings of git, I can only assume it uses a similar strategy to that of libraries you reference: structural sharing. Under the hood the libraries use tries or other trees to only track the nodes that are different.

This strategy is also reasonably performant for in-memory data structures as there are well-known tree-operation algorithms that operate in logarithmic time.

Another use case: say you want an undo button on your webapp. With immutable representations of your data, implementing such is relatively trivial. But if you rely on mutation, that means you have to worry about caching the state of the world and making atomic updates.

In short, there's a price to pay for immutability in runtime performance and the learning curve. But any experienced programmer will tell you that debugging time outweighs code-writing time by an order of magnitude. And the slight hit on runtime performance is likely outweighed by the state-related bugs your users don't have to endure.