Hacker News new | comments | show | ask | jobs | submit login

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...




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: