Hacker News Reader

Comment by bcherny | Hacker News Reader

Bummer. The latest web trend is immutability and event streams, but javascript data structures are almost all mutable by default, and O.o is a great way to take advantage of that fact. Instead of abstracting away data changes behind events, why not use data directly? Instead of fighting the language, why not (at times) embrace mutability?

View on HN

Alternatively, why not embrace immutability and add native immutable data structures to JS? I believe there is a TC39 proposal for this, in fact. Even if O.o had become mainstream, I would've stayed away from it. The immutability trend is not due to the impracticality of dealing with object observation, but due to inherent issues with mutable state.

Here's that proposal. https://github.com/sebmarkbage/ecmascript-immutable-data-str...

ha! i actually commented on this guy a few months ago. javascript is designed in such a way that i think true, clojure-like immutable data structures are not possible. we'd either need to overload comparators (===, ==) so that they compare immutable data by value (rather than by reference, which is the case for their mutable counterparts), or implement java-style .equals methods for immutable objects (or as static methods on their constructors). neither seems to be a great fit for javascript.

see my comment here https://github.com/sebmarkbage/ecmascript-immutable-data-str...

I think performance is the reason, but that's only speculation from a long-time JavaScript developer with plenty of in-the-trenches experience on resource-constrained platforms.

The platforms that do not shy away from data and embrace mutability at all times -- I believe those are called databases, and when necessarily distributed for scale, that mutability is the enemy of consistency.

Reply on news.ycombinator.com