DEV Community

Discussion on: Tight Code 1: When immutability goes bad

Collapse
 
miketalbot profile image
Mike Talbot ⭐ • Edited

So:

a) You can find dozens of examples on this site that use immutability incorrectly - as I said, I don't disagree it can be useful, but don't just believe you need to keep local things immutable and that's what immer helps with.

b) Immer js is brilliant! It's not magic though. What immer's benefit is that it commits your mutable transactions at the end of a process, not in the middle alleviating a ton of thinking and potential slowness. It's still between 20 and 40 x slower than mutating an array in the example I gave. Now this makes is pretty useful in most UI circumstances, you can probably afford that kind of overhead in many circumstances.

Collapse
 
louy2 profile image
Yufan Lou

I see. It is indeed a good thing to have one most post so people are more likely to stumble upon this information.

Thanks for the benchmark! I agree immutability is not free. Even Haskell uses internal states within high performing data structures.

Thread Thread
 
miketalbot profile image
Mike Talbot ⭐

Agreed, I mean my projects nearly 100% use some kind of immutability - my whole currently developed system is predicated on using transaction records and never mutating core data. I also love immer.js.

What I want to do in this series is just to point out - sometimes we should examine things in the tightest parts of our code if we are striving for 60fps. Oh yeah, and never do that stuff with [...blah, newThing] if there's a chance we will do it often! - That is just silly :)!!