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.
I'm pretty sure that if you report an actual bug and submit a pull request, it'll be merged in no time, as the "Closed" list suggests. You can hardly call that unmaintained.
I went through the pull requests and checked 5 or so that were open for a long time, all of them were glaringly missing something.
Some do not pass tests, some have obvious styling issues, some people haven't signed the contributor agreement, some offer big changes with very little reasoning behind it.
I also prefer projects that are more explicit about the reason something is rejected and answer RTFM-type issues, but this is not a requirement to be a successful project.
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.
I considered ImmutableJS a little while back. It's a great library but it makes you to a lot of work to go back and forth between native JS objects, and just abstracts you from the real objects underneath.
Instead I ended up just deepFreezing my data (only in development) and wrote a bunch of pure functions which perform all the important array/object functions but return a new array/object instead of mutating. It was a really great exercise in functional programming and I'd recommend it to anyone wanting immutable data and to understand immutable programming styles.
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.
Documentation should absolutely be technical, exhaustive, and.. I dunno what to call it, "written for people who know what they're doing."
Then have a load of general examples to cover the non-experts and initiates. There's no faster way to learn how to begin using a library than to look at some complete examples. That's the one thing that Immutable documentation misses. I wish there was a "Show example" link on almost every non-trivial method.
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.
But at least they shouldn't use phrases like `persistent sets` in the documentation. I confused that with the datatype on my first reading. Technical details are necessary but that is just creating unnecessary confusion. Compare that to the haskell documentation:
A map from hashable keys to values. A map cannot contain duplicate keys; each key can map to at most one value. A HashMap makes no guarantees as to the order of its elements.
The implementation is based on hash array mapped tries. A HashMap is often faster than other tree-based set types, especially when key comparison is expensive, as in the case of strings.
Many operations have a average-case complexity of O(log n). The implementation uses a large base (i.e. 16) so in practice these operations are constant time.
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?
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".
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.
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".)
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.
Care to explain why? Are you saying that immutable app states such as React/Redux shouldn't exist either? No wonder you got downvoted, just giving rants without proper arguments.
This isn't helpful. This would be especially unhelpful and counter-productive within a team. Rather than criticize you could offer kind guidance on how the original author could improve. Who knows, perhaps we will disagree with your choices just as strongly?
[+] [-] seattle_spring|9 years ago|reply
[+] [-] ht85|9 years ago|reply
I went through the pull requests and checked 5 or so that were open for a long time, all of them were glaringly missing something.
Some do not pass tests, some have obvious styling issues, some people haven't signed the contributor agreement, some offer big changes with very little reasoning behind it.
I also prefer projects that are more explicit about the reason something is rejected and answer RTFM-type issues, but this is not a requirement to be a successful project.
[+] [-] shados|9 years ago|reply
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.
[+] [-] _uhtu|9 years ago|reply
Instead I ended up just deepFreezing my data (only in development) and wrote a bunch of pure functions which perform all the important array/object functions but return a new array/object instead of mutating. It was a really great exercise in functional programming and I'd recommend it to anyone wanting immutable data and to understand immutable programming styles.
[+] [-] SomeCallMeTim|9 years ago|reply
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
[+] [-] Waterluvian|9 years ago|reply
Then have a load of general examples to cover the non-experts and initiates. There's no faster way to learn how to begin using a library than to look at some complete examples. That's the one thing that Immutable documentation misses. I wish there was a "Show example" link on almost every non-trivial method.
[+] [-] ht85|9 years ago|reply
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.
[+] [-] Tarean|9 years ago|reply
A map from hashable keys to values. A map cannot contain duplicate keys; each key can map to at most one value. A HashMap makes no guarantees as to the order of its elements.
The implementation is based on hash array mapped tries. A HashMap is often faster than other tree-based set types, especially when key comparison is expensive, as in the case of strings.
Many operations have a average-case complexity of O(log n). The implementation uses a large base (i.e. 16) so in practice these operations are constant time.
[+] [-] agconti|9 years ago|reply
[+] [-] Klathmon|9 years ago|reply
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?
[+] [-] alexhayes|9 years ago|reply
[+] [-] acidbaseextract|9 years ago|reply
[+] [-] pimlottc|9 years ago|reply
[+] [-] Illniyar|9 years ago|reply
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|9 years ago|reply
[+] [-] BinaryIdiot|9 years ago|reply
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|9 years ago|reply
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".)
[+] [-] diegorbaquero|9 years ago|reply
@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|9 years ago|reply
The author spoke about performance and immutability-data structures like Directional Acyclic Graphs and Trie.
[+] [-] garysieling|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] n0us|9 years ago|reply
[+] [-] relics443|9 years ago|reply
[deleted]
[+] [-] diegorbaquero|9 years ago|reply
[+] [-] lsadam0|9 years ago|reply