Or, you know, just use Object.freeze and you don’t have to give up any of the debugability and familiarity of standard JS Objects and Arrays.
That won’t help you with creating new versions that share structure with the unchanged old versions.
No it won’t, you’d need 2 or 3 functions for that, if you don’t want to use es6 syntax. What you don’t need is a bunch of alien pseudo-records and pseudo-arrays that none of your debugging tools understand.
Implementing e.g. a persistent HAMT, like the one used in immutable.js, is a bit more work than 2 or 3 functions.
I’m interested in how ES6 syntax would give me persistent data structures, though.
You don’t need all that stuff. I know this is going to sound like a tautology, but the benefits of immutability in a single-threaded environment aren’t in immutability, they’re in data not changing. Not having to deep-compare your data for changes. As long as you’re deep-freezing arrays and objects in your development and testing environments, you know your application code operates as if the data were immutable and you get all the benefits. At runtime in browsers that don’t support Object.freeze you simply stub it out.
By ES6 syntax I just mean using the object / array spread syntax instead of some sort of helper method to copy unchanged values. Let the browser vendors worry about hashing implementations and garbage collection. Let Flow or TSX handle the parts of ImmutableJS that are implementing half-assed types. Your code will be easier to read, and you can still implement specific optimisations if and where they become necessary.
I think we are focusing on different properties of these data structures, and therefore seeing different value (or lack of) in them.
Like you say, “data not changing” doesn’t require any special data structures, but is also not very interesting in itself.
When you combine it with efficient “updates,” you can make things like git, or combined with FRP, make a time-traveling debugger, to give some examples. They aren’t in competition with the built-in arrays/maps/sets, because they have entirely different design goals/tradeoffs, and neither is a good replacement for the other. I’ll take your word for them being difficult to debug in JS—I use the equivalent mutable and immutable/persistent data structures in other languages, and would also be annoyed if they didn’t play nice with the tooling.
It’s not available as an NPM module, so it’s not interesting ;)