Immutable is intended to bring persistent data collections to Javascript. Pioneered by Facebook, it is open source and has just reached version 3.0.0. 

Inspired by functional programming languages, Immutable is a JavaScript library that produces data that cannot be changed once created, leading to much simpler application development, no defensive copying, and enabling advanced memoization techniques.

The Read.ME on Github explains both the why:

Much of what makes application development difficult is tracking mutation and maintaining state. Developing with immutable data encourages you to think differently about how data flows through your application.

and the how:

Immutable provides List, Stack, Map, OrderedMap, and Set by using persistent hash maps tries and vector tries as popularized by Clojure and Scala. They achieve efficiency on modern JavaScript VMs by using structural sharing and minimizing the need to copy or cache data.

It also points out that this model of data flow aligns well with the architecture of React (another Facebook initiative that has just reached release 1.12)  and especially well with an application designed using the ideas of Flux (also Facebook initiated).

Immutable v3.0.0 introduces a number of new concepts, renamed methods, and other breaking changes which, according to Lee Byron have been motivated by the fact that:

Immutable aims to be to be idiomatic JavaScript. More than that, it tries to mirror existing related ES6 specifications. It expands on these specs while attempting to maintain the spirit of these specs.

Byron also notes a move towards "eager operations":  

Perhaps the biggest conceptual change is that all collection operations (filter, map, take, skip, slice, etc.) are no longer Lazy by default.

He provides as an example that in Immutable v2.x.x, a common pattern is to follow a collection operation with a.toXXX() method to convert back into the original type.

As Immutable v3, operations like this are now eager, the explicit conversion is no longer necessary.

// Immutable v3
myMap.filter(somePredicate)
// Map { ... }

He comments:

Lazy operations are still possible, and in cases where more than one collection method are used together, or the end result should be of a different type, it can result in a performance improvement by removing intermediate allocations.

Lazy evaluation is now only possible if you make an explicit conversion to the Seq type before applying map, filer etc. which some might regard as shame. Lazy evaluation in Immutable is mostly about performance rather than semantics as there are no infinite collections. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info