Why should I use immutablejs over object.freeze?

Question

I have researched on net about the benefits of immutablejs over Object.freeze() but didn't find anything satisfying!

My question is why I should use this library and work with non native data structures when I can freeze a plain old javascript object?

Answer 1

I don't think you understood what immutablejs offers. It's not a library which just turns your objects immutable, it's a library around working with immutable values.

Without simply repeating their docs and mission statement, I'll state two things it provides:

1. Types. They implemented (immutable) infinite ranges, stacks, ordered sets, lists, ...

2. All of their types are implemented as Persistent Data Structures.

I lied, here's a quote of their mission statement:

Immutable data cannot be changed once created, leading to much simpler application development, no defensive copying, and enabling advanced memoization and change detection techniques with simple logic. Persistent data presents a mutative API which does not update the data in-place, but instead always yields new updated data.

I urge you to read the articles and videos they link to and more about Persistent Data Structures (since they're the thing immutablejs is about), but I'll summarise in a sentence or so:

Let's imagine you're writing a game and you have a player which sits on a 2d plane. Here, for instance, is Bob:

var player = {   name: 'Bob',   favouriteColor: 'moldy mustard',    x: 4,   y: 10 }; 

Since you drank the FP koolaid you want to freeze the player (brrr! hope Bob got a sweater):

var player = Object.freeze({     name: 'Bob',     ... }); 

And now enter your game loop. On every tick the player's position is changed. We can't just update the player object since it's frozen, so we copy it over:

function movePlayer(player, newX, newY) {     return Object.freeze(Object.assign({}, player, { x: newX, y: newY })); } 

That's fine and dandy, but notice how much useless copying we're making: On every tick, we create a new object, iterate over one of our objects and then assign some new values on top of them. On every tick, on every one of your objects. That's quite a mouthful.

Immutable wraps this up for you:

var player = Immutable.Map({     name: 'Bob',     ... });  function movePlayer(player, newX, newY) {     return player.set('x', newX).set('y', newY); } 

And through the ﾉ*✧ﾟ magic ✧ﾟ*ヽ of persistent data structures they promise to do the least amount of operations possible.

There is also the difference of mindsets. When working with "a plain old [frozen] javascript object" the default actions on the part of everything is to assume mutability, and you have to work the extra mile to achieve meaningful immutability (that's to say immutability which acknowledges that state exists). That's part of the reason freeze exists: When you try to do otherwise, things panic. With Immutablejs immutability is, of course, the default assumption and it has a nice API on top of it.

That's not to say all's pink and rosy with cherry on top. Of course, everything has its downsides, and you shouldn't cram Immutable everywhere just because you can. Sometimes, just freezeing an object is Good Enough. Heck, most of the time that's more than enough. It's a useful library which has its niche, just don't get carried away with the hype.