Hacker News Reader

Comment by abaco | Hacker News Reader

Bit confused (ignorant actually) here. Can someone give a 'real world' example of the benefits of immutabile objects in js?

View on HN

The first time I understood why immutable objects are important was in this podcast with ClojureScript and Mori author David Nolan: http://podcasts.thoughtbot.com/giantrobots/93

What I thought was the key point was this:

Let's say you have a regular JS array. There is a reference to it in memory and it has a certain value. Now you change an element in that array. You've just mutated it. In JS, the reference in memory doesn't change, but now the value of what it's pointing to has. So in order to know if the value has changed, you need to do a comparison on every element on that array, which is expensive.

Now let's say you have a immutable array (such as from the Immutable FB library or Mori). If you change an element in that array, you get a new array and a new array reference in memory. In other words, if you check that the reference in memory is the same, you are guaranteed that the value is the same (in this case, the array). So checking for equality is fast and cheap because you are only checking the reference, not each value in the array.

One way this is important in React is that now if your component state (or entire app state) is represented by an immutable data structure, you can just check for reference equality in the shouldComponentUpdate() method when deciding to re-render that component. If the reference is equal, you are guaranteed that the data backing that component hasn't changed and you can return false, telling React not to re-render.

What's surprising is that people have made these data structures also very memory efficient. You can see David Nolan talking about how they work and memory comparisons here: https://www.youtube.com/watch?v=mS264h8KGwk

Note that you can have cheap equality detection by using e.g. flags or revision counters and so on (but there are limits due to JavaScript's nature..). The problem is that JavaScript currently doesn't support this properly out of the box, but Object.observe is coming in the next standard.

I personally like the safety benefits of immutability. You can give objects to functions and not worry about the functions changing the object. The only way to guarantee that otherwise is to clone the object, but that takes quite a bit of performance.

The difference is that if you use Object.observe to track changes, then you don't have the ability to hold onto the previous version of an object and know what the old value was.

This is important for animations where you want to animate from the object's old value to the new value.

The objects passed to the Object.observe callback function describe both the new value and the old value, FWIW.

Isn't this library probably cloning?

If you watch the linked video above you will see how clever persistent data structures mean that nothing is ever cloned or copied.

Good to know. I never got into immutable collections because I presumed they would result in things being allocated all the time (and that that would be expensive).

I'd guess this library clones on modification, but I was talking about cloning the object on every function call.

Persistent data structures allow for the appearance of cloning (you have a new thing) but are much more efficient behind the scenes (you don't actually copy everything). So if you find yourself doing a lot of defensive cloning, then Mori or this library would probably be a lot faster for you.

Absolutely! If anyone is reading this, I recommend Eric Lippert's 11 part series on immutability in C#. The concept apply everywhere, of course.

http://blogs.msdn.com/b/ericlippert/archive/2007/11/13/immut...

Immutable objects in general or immutable objects in JavaScript specifically?

A general example would be good :)

It is a guarantee to you that the data structure has not been tampered with by the time it reaches you.

    // pseudo code

    var fruitBasket = new FruitBasket('banana, 'apple)

    muckWithFruits(fruitBasket)
    suspiciousLogger(fruitBasket)
    weirdCallback(fruitBasket)

    // here
    assert(fruitBasket.length == 2)

By the time we reach "here", we know that none of the functions since the inception of fruit basket have tampered with it.

This may not be a big deal if you are disciplined about never modifying your source data, but this moves the guarantee from a soft one to a mechanical one.

And then there's all this typical stuff about functional programming blah blah... But that's the most practical example I can think of.

If everything is immutable, it also makes it a lot easier to parallelize tasks, because you can easily deduce a dependency graph.

In multi-threaded environments, immutable objects are thread-safe. When multiple threads are sharing data, you would normally have to worry about synchronization. However, immutable data structures guarantee that the shared data will not change, so synchronization issues simply go away.

That said, I'm not sure how this applies to JS, which is single-threaded.

Even though it's single-threaded (not with web threads maybe?), it can still be asynchronous, which is where the issues really lie.

Reply on news.ycombinator.com