I think this is an example of something I see often, where a particular idea (e.g. immutability, interfaces, modularity, etc.) gets confused with a particular f

I think this is an example of something I see often, where a particular idea (e.g. immutability, interfaces, modularity, etc.) gets confused with a particular feature of a particular language which shares the same name. In this case, the author's code isn't using immutability; it just-so-happens to be creating an object called "Immutable.Map". Following the author's terminology, mutability is when we replace the contents of a memory location with different values, e.g.: Time | RAM ------+-------------------------------- 0 | foo 1 | bar 2 | baz . . . The author is using the term immutable to mean never replacing the contents of a memory location, so in their view this is immutability: Time | RAM 1 | RAM 2 | RAM 3 | ------+-------+-------+-------+--... 0 | foo | | | 1 | foo | bar | | 2 | foo | bar | baz | . . . . . . . . . . . . However, this is really just an implementation detail; Javascript programming isn't really about values in RAM (unlike, e.g. C where pointers are first-class values in the language). Instead, Javascript is conceptually built around variables, objects, scope, etc. So let's see how these RAM details translate to the values of variables. The "mutable" version: Time | "state" var ------+------------- 0 | foo 1 | bar 2 | baz . . . The "immutable" version: Time | "state" var 0 | "state" var 1 | "state" var 2 | ------+---------------+---------------+---------------+--... 0 | foo | | | 1 | foo | bar | | 2 | foo | bar | baz | . . . . . . . . . . . . So far so good. However, scope plays a large part in Javascript programming: we can only access variables which are in scope, and what's more the same variable name can refer to different values depending on the scope we're in. This is where the author confuses the concept of immutability with the name of a library they just-so-happen to be using. Their code keeps generating new scopes, in which the variable name "state" refers to a different value than in the previous scopes. Conceptually, the variable "state" is not immutable because it keeps referring to different things, even though the implementation details could be argued to be immutable. As an analogy, consider a display which shows the current value of a stock price. That is certainly not immutable, and trying to use that reading to perform calculations will be tricky since it keeps changing. This is like the author's original, mutable "state" variable. Now consider a plotter drawing a graph of how that price varies over time: | | _--. ____ Price | / \ / \ |__/ \__; \__/ | +----------------------------------- Time ^ | Now This is like the author's "immutable" version, where values are never changed once they're defined. This seems more useful for performing calculations, however, because the author keeps creating new scopes, they have no access to these old values! We have no access to the graph paper, we're only allowed to see the current position of the pen; which is exactly the same as if we only had the original display! If we take scope into account, we actually get the following: Mutable version: Time | Scope | Current "state" ------+-------+----------------- 0 | 0 | foo 1 | 0 | bar 2 | 0 | baz . . . . . . Immutable version: Time | Scope | Current "state" | "state" var 0 | "state" var 1 | "state" var 2 | ------+-------+-----------------+---------------+---------------+---------------+--... 0 | 0 | foo | foo | | | 1 | 1 | bar | foo | bar | | 2 | 2 | baz | foo | bar | baz | . . . . . . . . . . . . . . . . . . I do think the author has a few good points to make; however, I don't think it's an argument between being mutable vs. being immutable, so much as one between being implicit vs. being explicit.