seamless doesn't implement the "persistent" part of immutable persistent data structures. The persistent part means you can create a cheap modification of the data structure, with structural sharing between "copies".

The main benefit I derive from immutability in js is identity comparison (I.E. react's shouldComponentUpdate), I don't find the small performance hit of cloning to make a difference.

What do you mean? I'm pretty sure it only clones the minimal necessary.

I.E. if I have {a:{aa:"1"},b:"cc"} and I change b, then {aa:"1"} will not be deep copied.

Are you talking about something like keeping a reference to the parent and sending lookups up the chain (with a prototype or some such?)

The simplest example would be a persistent list. Think you first create a list [c,d,e]. You can safely share references to that. Then you attach a to one version and b to another:

    a \
       c-d-e
    b /

The memory for the original list is still shared! You can generalize that to trees and use that to implement, say, persistent hashmaps that can share data.

This is also awesome for parallelization where you want to share data but don't need synchronization!

The person you are replying to is talking about things like maps implemented with persistent trees. Updating a value in such a map generally only involves copying O(log N) nodes in the tree: It's not necessary to shallow copy the entire tree itself.

And immutable.jsdoes that?

Oops, didn't realize that seamless does its own shallow copying strategy with `merge`, `set`, `setIn`. I can't speak to how this compares to persistent data structures implemented by immutable.js, clojure, elm, etc. But it looks like the seamless author said the following about it:

> Persistent data structures are different, as their performance improvements are passive. Although seamless-immutable does not (and cannot, while maintaining its backwards compatibility with vanilla JS collections) use things like VLists under the hood, its cloning functions—such as merge—only bother to make shallow copies, as shallow and deep copies of immutable values are equivalent. In practice, this simple passive optimization has been sufficient; we have yet to encounter a performance problem that Bagwell-style persistent data structures would have solved.

from: http://tech.noredink.com/post/107617838018/switching-from-im...

Aye. I found its interface to be simpler but it quickly became clear that it was fundamentally useless since I lost the performance gains of partial mutations that left unmutated parts of the structure with the same reference.