
Immutable.js: An Introduction with examples written for humans - rcdmd
http://untangled.io/immutable-js-an-introduction-with-examples-written-for-humans/
======
seattle_spring
Immutable.js would be great if it were actually maintained. FB hasn't made or
approved a real pull request since April, and there are hundreds of pending
issues that haven't been addressed or even responded to in over a year.

~~~
shados
Which is somewhat ironic, considering half of the reason to use it over Mori
(which is better in some aspects) was that it was more maintained (Mori didn't
pull anything in ages).

Now neither of them are really maintained.

For a lot of usages, something like Ramda or Lodash/FP will do the trick
(Ramda lenses or Lodash/FP's get and set methods work great to handle
immutable data structures), but if you really wanted structural sharing and
stuff, now you're kindda stuck.

~~~
jdd
You might dig mudash – Lodash wrapper providing immutable.js support

[https://github.com/brianneisler/mudash](https://github.com/brianneisler/mudash)

~~~
shados
That's not the issue (we have our own lodash-ish thing for immutablejs at
work). Its that immutablejs itself isn't maintained much. Doesn't matter how
many layers you put on top.

------
SomeCallMeTim
First, TypeScript type definitions are _almost_ the same as standard
JavaScript JSDoc type annotations, so (to the level they're used in
Immutable.js), yes, people should learn them.

Second, TypeScript should be considered a best practice for nontrivial
JavaScript development in 2016. And pretty much any app that would benefit
from Immutable.js would be "nontrivial" by that definition.

Third, everyone using JavaScript or TypeScript knows what a Map is, I would
hope. The docs for it that read "Immutable Map is an unordered Iterable.Keyed
of (key, value) pairs with O(log32 N) gets and O(log32 N) persistent sets."
are perfectly legible to me, having never used Immutable.js, just because I
had a few undergrad (not "a Ph.D.") computer science classes. I don't even
have a computer science degree [0] at all.

I actually personally despise lowest-common-denominator docs: Docs that tell
me "what a Map is and how to use it" when what I want to know are things like
what its get and set performance implications are, and whether you can iterate
over it, and whether that iteration will be ordered, and so forth.

Sure, create a user's guide, but don't pick on the reference manual for being
concise.

FWIW, I'm not a big fan of Immutable.js or immutable structures at all. I'm
too performance-oriented to want a layer like that between me and the
underlying data structures. Criticize it for being unmaintained [1], sure, but
not for having docs that aren't aimed at beginners.

[0] My degree is a B.S. in Cognitive Science [1]
[https://news.ycombinator.com/item?id=13051458](https://news.ycombinator.com/item?id=13051458)

~~~
ht85
I feel the same about lowest common denominator, and even though facebook and
google documentation can be on the far end of the austere spectrum, they are
still putting out incredible libs for free.

For your comment about performance, immutable structure being comparable by
reference can provide huge gains in read and re-use heavy environments, thanks
to memoization-like techniques.

~~~
SomeCallMeTim
>For your comment about performance, immutable structure being comparable by
reference can provide huge gains in read and re-use heavy environments, thanks
to memoization-like techniques.

Fair enough. I'm often doing things to graphics, and the concept of using
immutable data when the data is a bitmap with 4Mb of pixels, and you're trying
to draw hundreds of sprites or shapes to it...well, let's just say that
immutable doesn't make sense for that.

Even when I'm just working on a game, though, the more frequent allocations
required by copy-on-write structures means more fragmentation of the heap and
more deallocations later. Ideally during runtime _nothing_ gets allocated.

You may even be right that the _amortized_ speed of using immutable structures
is the same as doing it with mutable data. But anything that adds a lot of
allocations and therefore adds to the frequency of garbage collection will
cause (or increase) jankiness in a game.

You have 16.66ms to accomplish _all the work_ for a frame. If a garbage
collector comes along and steals even 10ms, if you can't do the remaining work
in 6.6ms, it will skip a frame, and users will see it.

And my current game needs to run in a browser, at least mostly. So here I am.
:)

------
agconti
The sites down, here's the cached version:
[http://webcache.googleusercontent.com/search?q=cache:5fXNOBY...](http://webcache.googleusercontent.com/search?q=cache:5fXNOBYia1AJ:untangled.io/immutable-
js-an-introduction-with-examples-written-for-
humans/+&cd=1&hl=en&ct=clnk&gl=us)

~~~
Klathmon
This is off topic, but is the traffic from HN really that great?

It seems like websites are dead pretty often on HN, but on sites like Reddit
where I assume there is a magnitude more traffic they seem to hold up pretty
well (with some exceptions).

So what's going on here? Does HN really have a bunch of silent viewers? Or is
it something more benign like sites that get submitted are often smaller?

~~~
technion
This actually says a lot about web technologies.

When I posted a recent high ranking blog post[0], I received around 18,000
views over the next 24 hours according to Google Analytics. I don't believe
this covers a lot of the bots and associated traffic that also crawled the
site.

This amount is nothing for a Jekyll site, I had CPU hovering at around 4%,
with a series of services also running on this server. This is, imo, where a
"hug of death" _should_ end.

I did however at the time, have several colleagues in web development express
shock and awe at the fact the site stayed online with traffic levels such as
this. Multiple people tried to school me on the need for Cloudflare at this
incredible scale.

A lot of web developers think about "scale" in terms of many bloated CMS
platforms, and it is with no surprise that the site in question is running
Wordpress.

We had a friend's site a while back where we worked out, with just two
desktops and spamming "F5" on the keyboard, we could take the site offline,
and take several minutes to recover from after the fact. He went and posted
for help on Reddit, and sure enough, the consensus was that his experience
involved far more traffic than any website could reasonably be expected to
handle.

Your answer therefore lies not in the silent HN users, but in the unusually
poor performance of popular CMSs. And although I'm using Wordpress, it's not
alone in this situation. [0]
[https://news.ycombinator.com/item?id=12973181](https://news.ycombinator.com/item?id=12973181)

~~~
Klathmon
See I understand the reasoning behind it, but I don't think that's it alone.

I'm saying that the frequency I see the "HN hug of death" is much more than
the "Reddit hug of death" while having many of the same kinds of sites (the
"bloated CMS platforms" you talk about).

------
alexhayes
I don't know if it's my eyes but I find those coding examples extremely hard
to read because of the colour palette used.

~~~
acidbaseextract
Going to echo this, really hard to read, both because of the color palette and
the bizarre white spacing between the black lines of code.

------
Illniyar
I find seamless-immutable to be much much better. It mostly follows the
standard javascript api, and throws an error when you use a mutable action.

Makes it very simple to use it anywhere you'd use a plain array or object,
rather then always having to use immutable.js's api.

~~~
undershirt
seamless doesn't implement the "persistent" part of immutable persistent data
structures. The persistent part means you can create a cheap modification of
the data structure, with structural sharing between "copies".

~~~
Illniyar
What do you mean? I'm pretty sure it only clones the minimal necessary.

I.E. if I have {a:{aa:"1"},b:"cc"} and I change b, then {aa:"1"} will not be
deep copied.

Are you talking about something like keeping a reference to the parent and
sending lookups up the chain (with a prototype or some such?)

~~~
moon_priestess
The person you are replying to is talking about things like maps implemented
with persistent trees. Updating a value in such a map generally only involves
copying O(log N) nodes in the tree: It's not necessary to shallow copy the
entire tree itself.

~~~
Illniyar
And immutable.jsdoes that?

~~~
undershirt
Oops, didn't realize that seamless does its own shallow copying strategy with
`merge`, `set`, `setIn`. I can't speak to how this compares to persistent data
structures implemented by immutable.js, clojure, elm, etc. But it looks like
the seamless author said the following about it:

> Persistent data structures are different, as their performance improvements
> are passive. Although seamless-immutable does not (and cannot, while
> maintaining its backwards compatibility with vanilla JS collections) use
> things like VLists under the hood, its cloning functions—such as merge—only
> bother to make shallow copies, as shallow and deep copies of immutable
> values are equivalent. In practice, this simple passive optimization has
> been sufficient; we have yet to encounter a performance problem that
> Bagwell-style persistent data structures would have solved.

from: [http://tech.noredink.com/post/107617838018/switching-from-
im...](http://tech.noredink.com/post/107617838018/switching-from-immutablejs-
to-seamless-immutable#performance)

------
BinaryIdiot
I've never seen code in which someone actually uses Immutable.js in a way
that's superior than using the built-ins. In fact even this introduction the
examples seem terribly contrived.

I'm not convinced this library is really that useful in a dynamic language.
Considering the top 2 immutable libraries (Mori and now Immutable.js) are both
essentially abandoned I get the feeling the public opinion is likely the same.

~~~
WorldMaker
The decision axis for something like Mori or Immutable is not so much static
versus dynamic typing but imperative versus functional code. Immutable/Mori
lends itself handily to cases where you are writing a lot of pure functions
that output a different state rather than manipulate an existing state.
Immutable/Mori can help you ensure that your pure functions stay pure by
making it almost impossible to mutate an existing state.

If you are less concerned with pure functions and happy with largely
imperative or hybrid imperative code, then yes it is difficult to find a
compelling example for Immutable.

(Immutable seems almost entirely stable at this point and covers just about
the entire necessary API surface, so I think it's a case to call it "mature"
rather than "abandoned".)

~~~
BinaryIdiot
> If you are less concerned with pure functions and happy with largely
> imperative or hybrid imperative code, then yes it is difficult to find a
> compelling example for Immutable.

Meh, I don't see a lot of usage even with pure functions. JavaScript never
really had any protections in it (minus the new-ish const and Object.freeze())
so most developers I know simply write as if something else has access to an
object then it will mess with it so everything gets architected accordingly.
Just seems to me a mostly non-issue in the JavaScript world.

> so I think it's a case to call it "mature" rather than "abandoned".

No I would most certainly call it abandoned. They have countless issues and
pull requests from over half a year ago without even a single response from a
human. While it may be a mature product, I would still call it abandoned.

~~~
WorldMaker
Just because JS historically hasn't had too many protections built in doesn't
mean that adding protections from a library aren't useful. Especially if you
are coding from a functional language perspective (and not everyone believes
this but JS can be a rather good functional language if you let it; it's not
terribly far removed from the ML/OCaml family).

For what it is worth, anecdotally, I've been doing a lot of heavy work with
RxJS observable pipelines (in a CycleJS-based application) where Immutable has
absolutely made a big difference in performance and stability of complex "four
dimensional" (lots of changes over time) "shared nothing" (pure) state
tracking.

That may be a use of the language and a complex learning curve of a framework
setup in which you never plan to work, but it's definitely an "issue" where
libraries like Immutable and Mori turn out to be extremely useful (whether or
not you think they are abandoned).

I've heard similar anecdotes from people using various combinations of things
like React and Redux with Immutable.

~~~
BinaryIdiot
Fair enough. I wouldn't be surprised a lot of folks found good uses for
Immutable.js. I just hadn't seen anything that would appear to benefit from it
in my travels and I think having immutability is a bit oversold IMO :)

------
diegorbaquero
Great article. I wonder what the performance implications would be vs using,
for example, native (mutable) arrays. Such addition of analysis to the article
would've made it just perfect.

@alexhayes it is a common color palette, I was going to link the most common
place where I find it but I forgot about it, haha.

~~~
victorcase
@diegorbaquero you should watch that [https://www.youtube.com/watch?v=I7IdS-
PbEgI](https://www.youtube.com/watch?v=I7IdS-PbEgI).

The author spoke about performance and immutability-data structures like
Directional Acyclic Graphs and Trie.

------
n0us
I always thought their documentation was excellent tbh.

