Web Development Business

Immutable Objects in JavaScript

Casey Justus JavaScript, Opinion, Technology Snapshot 2 Comments

There are very good reasons to use immutable objects in certain languages. In JavaScript, however, I’m still kind of…. meh.

In this blog post, I plan to discuss my reasonings with the hope that I might spark discussion on the use of Immutable Objects in JavaScript.

What Are Immutable Objects?

The definition of mutable is “liable or subject to change or alteration.” When discussing programming, we use it to indicate objects that are allowed to change over time. So, conversely, an immutable value is the opposite – after that object is first created, it cannot be changed. It is not variable.

Basically… immutable objects means that you are always creating new objects (or entire data structures) as opposed to making individual changes to those existing objects in the original data structure.

Why Are Immutable Objects Used?

The main reason for immutable objects is that they are thread safe. This makes sense in some languages.

But as JavaScript is single threaded, this doesn’t really apply. And when you use web workers to take advantage of multi-threading in JavaScript, you’re using a messaging interface that helps to keep you out of trouble with the state of your objects.

Performance is debatable for immutable objects. They use a larger memory footprint but in some situations can reduce the number of processes. The most important performance issue for a model though is its impact on DOM rendering.

But When Applied to React.js Apps…

Facebook’s React.js is a popular view framework – that’s the V in MV*. It also has a library for models called Immutable.js.

See Also:  More on Accessibility-First Programming

For React apps, it makes some sense to use Immutable.js. React uses the Observer Pattern to update the View on a change to its Model.


Whether you like React or not, there is some simplicity in not having to write specific binds between the Model and View. And the expensive process of observing all objects isn’t impacted by replacing the entire Model through Immutable.js. React creates a simplified, virtual DOM and compares this to the actual one to see if any updates need to be made.

With other MV* libraries however, you already have a Model with its own methods and way of binding the View to the Model. I think immutable JavaScript makes some sense for React apps but only depending on the application.

Sometimes native objects make more sense for React apps, not just for performance, but because you can use native arrays with a much more extensive list manipulation library like lodash.

Comments 2

  1. Thread-safety in JavaScript? Its single event loop thread supports asynchronous listener functions by dispatching them from its event loop. That means things happen pseudo-simultaneously. An async action could modify a single item at a wrong time, or with a wrong value for the time, driven only by sporadic human or network interactions.

    I could set a state in an app having listeners. Perhaps a keystroke tees up a method call to a lurking dormant function. On a subsequent browser event-loop crank-turn, that function updates the state. I hope my state is right for the time and place!

    Promises. click handlers, keystroke handlers, Ajax handlers, drop handlers, or reactive streams — all can update a closure variable at an arbitrary time. If that variable is part of mutable state, we could have a mess to reason about. That boils down to money.

    Immutable objects make it easier to reason about what can modify what, where, and under what circumstances. They are testable. These qualities engender lower costs through fewer bugs during development and promote less breakage through maintenance misunderstandings. JavaScript String and Java Strings have been immutable since forever, for these kinds of reasons.

    We (you young ones) will increasingly have noses rubbed in functional programming. This will drag in immutable objects. Learn to like them. Partly, the stimulus is Moore’s Law riding on more CPU cores instead of faster single cores. If state doesn’t mutate uncontrollably, it doesn’t matter what core receives what flow, when. Yes, something has to mutate in order to respond to requests, but we’ll strive to corral mutations into a single known place we can scrutinize.

    1. One more comment: immutable js doesn’t replace the entire model. It returns a new model that reuses the unchanged part of the structure of the old model. In other words it does an internal mutation, but insists on returning it as a new reference. I’d say that most immutable frameworks, libraries, or architectures in computer science use this “structural reuse” paradigm.

What Do You Think?