Implicit side-effects are hard to do

Side-effects in code that uses mutable data are implicit. Immutable.js, on the other hand, promotes explicit side-effects by placing them at the end of a method call chain. This makes the side-effects in your code easy to spot, and easy to reason our way through the sequence of transformations and persistent changes that lead up to the side-effect occurring.

Implicit side-effects are problematic because we don't have any meaningful way to track them. For example, you change some data that results in four function calls being made. Do any of them have side-effects? Two of them? All of them? Do the side-effects cascade into other side-effects? We're creating too much work for our brains to handle here.

The trick with Immutable.js is to make explicit the things that matter when you're reading code. This means quickly figuring out what caused a given side-effect to occur. On the other hand, you can't make everything explicit otherwise you'd have a mountain of code to sift through. The implicitness of Immutable.js comes with piecing together data by gluing it together using chaining—there's a lot going on behind the scenes that you don't need to think about.