How easy is it to write immutable Javascript?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at:

If you reinvent the language as a new language, then you can have immutable Javascript. On the frontend you have no choice, but on the backend? Why not use a language that offers what you need upfront, rather than forcing you to work for it? Interesting:

The main issue I’ve had using immutablejs with Redux is debugging. Whereas previously I could simply mouse-over a data structure when I hit a breakpoint (or crash), I now have to do a REPL dance to see what’s in any of my data structures.

I also find myself often having to do trial and error stuff to fix my code (also while in a paused state in the console). I mean it’s pretty nice that you can actually do this, don’t get me wrong. But overall, I am slower and less productive with immutablejs than I am with vanilla JS / JSON objects.

It’s a trade off people really should keep in mind before pulling the trigger on immutable data structures. Sure, you get that performance boost, but do you actually need it? Are your React views really so slow (or are you running on slow embedded hardware like I am)? Or are you just drinking the kool aid because immutable data is hot right now?

You get runtime perf improvements in certain cases, at the cost of opaqueness, productivity and complexity. Make sure it is worth it.

And a reply:

spion 1 day ago

The solution to this and similar problems is to define more protocols like the iteration protocol [1], but for showing objects, accessing their properties etc.
If libraries and tools rely on protocols instead of using built-in objects then we would be able to plug any kind of data structure implementing the required protocols into any kind of library that takes advantage of those protocols.