Explaining immutability
Roman Liutikov

Ok, so I get what immutability is. In the larger enterprise context, it makes sense, and many large-scale apps implement that through versioning, etc. Including most blogs, wikipedia pages, etc. It makes sense in the database layer and in the ability to pull those larger objects back and have an undo (to the extent that changes in the DB schema make it possible).

It makes sense in a smaller layer with undo/redo needs like editors, when not using the Command pattern(with undo instructions in them) to handle it.

But beyond that, I’m utterly unsold on their use in client applications. They seem completely at odds with how most applications, especially mobile, work, especially ones with settings where those settings are applied and persisted immediately. What is the point of keeping the old one around? I push a button, something happens, done. It is what I wanted to happen. I have no need for what the data looked like before it happened. Undo is not necessary in every application. Keeping the older versions of objects in memory is basically a memory leak by any other definition.

So can you “sell” me why, outside of undo/redo, immutable objects have any purpose in an app, especially a mobile html5 client app that needs to keep its memory footprint small?

Show your support

Clapping shows how much you appreciated Joe Shelby’s story.