Reasons I Dislike 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.
- Cannot use regular/ES6+ style
- Verbose in many ways
- References are a tool, not an enemy
- Third party libraries are not designed with Immutable.js in mind
- The performance boost it offers is rarely used
Not Standard Style
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
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.
So it is verbose in syntax, extra packages, and research time.
References Are A Tool
Any fetches to servers for JSON, or dealing with libraries led to a lot of
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
- 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.