Reasons I Dislike Immutable.js

Update June 11th, 2018 — A new library just came out called Immer — — it is immutability of objects/arrays using plain Javascript features. No crazy API. It has 4.7k stars in days of it’s release. It seems like a lot of people agreed with me in disliking Immutable.js!

I have been using Immutable.js library with my React & React Native projects for the past two months. I am definitely not the best with the library, and there probably are friendlier ways to accomplish what irked me, however I am not a fan. Here are some reasons why I dislike it.

  1. Cannot use regular/ES6+ style
  2. Verbose in many ways
  3. References are a tool, not an enemy
  4. Third party libraries are not designed with Immutable.js in mind
  5. fromJS + toJS galore
  6. The performance boost it offers is rarely used

Not Standard Style

Since the start of Javascript I am used to a certain style. ES6 built on top of this style very nicely. For instance destructuring from objects is so easy. This cannot be done with Immutable.js. We can install a third party babel plugin to give us this. However keeping libraries to a minimum, without rewriting existing functionality out there, is always a goal. With Immutable.js I find myself adding obscure babel plugins, and helper packages for libraries to use Immutable.js.

ES6 came in and built on the usual style. I do not find myself researching ES6 syntax nearly as much as I do Immutable.js syntax. Immutable.js does try to emulate ES6 style

Very Verbose

It is not only verbose in the syntax, but is verbose with requiring babel plugins and helper packages for compatibility with libraries (like redux-persist).

There are many ways to accomplish things with Immutable.js. I keep researching to find something more simple, I find more ways, but always verbose.

Simple React stuff cannot be done:

render() {
const appliedIds = [...];
return (
{ immutableMap.reduce( (arr, entry) => <Blah key={entry.get(‘id’)} id={entry.get(‘id’)} isApplied={appliedIds.includes(entry.get(‘id’)} /> }

Destructuring entry to {id} would help.

So it is verbose in syntax, extra packages, and research time.

References Are A Tool

Object references in Javascript are a tool. I like to be immutable at function boundaries, and mutable within. We can use the withMutations feature of Immutable.js but this leads to a complication of what has been built into Javascript from it’s inception.

Having done Javascript for a long time, I automatically keep in mind what is reference is pointing where. Immutable.js can possible reduce cognitive load, but it is abstract away a powerful feature/tool.

Other Libraries

A majority, if not all, libraries are designed with standard Javascript features. They do not consider and design for Immutable.js. When I bring in another library, I would have to do a lot of tweaking to get things working right. It is good to dive into libraries, but ideally libraries are plug and play. But with Immutable.js, everytime I add a library I have to spend time diving in to see how it works before using it. Most of the time I end up doing fromJS and toJS .

fromJS + toJS Abuse

Any fetches to servers for JSON, or dealing with libraries led to a lot of fromJS and toJS use. I might as well not be using immutable.

No Performance Gain

The most remarkable performance gain from using Immutable.js is in deep comparing immutable structures. I have never needed this in the past, but thought to try out Immutable.js I could maybe take advantage of deep comparison to discover new techniques. It didn’t. I had to force myself to try to take advantage of this, by doing a deep compare when I didn’t need to.

In the end… It slowed me down.. A lot!

Each of the above points contribute to slowing down development immensely. Cognitive load is increased with silly things, rather then useful things like “references”.

I use libraries to make me more efficient, make things easier. Immutable.js did not do that for me.

Immutable.js has made me write a lot more code to do simple things. It has made me spend more time researching syntax. Being more verbose, along with time spent having to research better ways, leads to it slowing me down a lot.

I admit, if I used Immutable.js enough I wouldn’t have to research. However what would prompt me to research was thinking, “doing X is so simple in regular/ES6 style, it can’t be this convoluted”. That thought will probably keep coming up.

The reason I chose Immutable.js in the first place was because of two points:

  • Deep setting in an object was an absolute breeze
  • Keys of objects can be numbers (useful for IDs) — helps me avoid parseInt
  • Deep compare perf— can maybe help me discover new approaches

After working with Immutable.js, the convenience given for deep setting, and avoiding a parseInt, is far outweighed by the cons. I also realized if I ever need to deep compare, I’m doing something wrong. Deep comparison is only useful during development/debugging.

I don’t dislike immutability, I think this offers some cool techniques. Especially at function boundaries.