The author mentions defensive object cloning, which is, in general, an unpleasant way of doing things. Using immutable data structures makes for a far saner development experience (although with Javascript as the underlying target, it probably means some automatic defensive copying anyway...).
Using mutable state obviously generates far, far less garbage, and we've run into all sort of problems of bumping up against the GC in trying to have fast-enough javascript, so it is tempting from a performance POV. Would be wonderful if immutable structures can eventually co-exist nicely with GC implementations.
Unfortunately there aren't any particularly efficient ways to do immutable values in JS right now. readonly properties tend to behave in poor ways (like silently discarding attempted writes, or slowing down jitted code) and immutability forces you to create way more object instances than you would otherwise (which, as the post mentions, tends to perform poorly due to the relative immaturity of JS GCs.)
At this point I consider this to be a bigger problem than it was when I wrote about it [1]. On the upside, it's possible to use tools like Emscripten or LLJS to produce JavaScript code that doesn't suffer from these downsides because it doesn't rely on the JavaScript GC or heap, but that introduces its own issues.
Ultimately, JS engines either need dramatically better garbage collectors or, the language needs to evolve to the point that an ordinary piece of JavaScript isn't going to place tons of pressure on the collector. Proposals like Binary Data [2] will help pave the way here but it may ultimately take the addition of value types that behave like structs in C/C#.
Using mutable state obviously generates far, far less garbage, and we've run into all sort of problems of bumping up against the GC in trying to have fast-enough javascript, so it is tempting from a performance POV. Would be wonderful if immutable structures can eventually co-exist nicely with GC implementations.
Great article, thanks for writing it!