Web Development Business

Immutable Objects in JavaScript

Casey Justus Development Technologies, JavaScript, Opinion 2 Comments

Attention: The following article was published over 8 years ago, and the information provided may be aged or outdated. Please keep that in mind as you read the post.

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.

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.

Thoughts

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.

0 0 votes
Article Rating
Subscribe
Notify of
guest

2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments