8 ms·
Immutable.js: An Introduction with examples written for humans
- relics443 10y agoThis article seems to highlight the many reasons why some people shouldn't code.
- diegorbaquero 10y agoCare 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.
- relics443 10y agoBecause saying things like: "the documentation describes the API in TypeScript, and then provides no examples at all! So the average JavaScripter can’t understand what the API looks like" And: "Add into the mix the way the documentation casually drifts into hard-core Computer Science and algorithmic discussions at inappropriate places, and you’re left with documentation that only the documentation’s auto-generator understands. Don’t believe me? Just see this example describing Map, one of the most-used Immutable data structures: Immutable Map is an unordered Iterable.Keyed of (key, value) pairs with O(log32 N) gets and O(log32 N) persistent sets. OK. Er, of course it is." If you don't know what you're doing, and you just want to know how to do it, everyone ends up suffering. And I don't know much about Typescript, but isn't it javascript with types? If the average javascripter can't figure out what's going on there...
- lsadam0 10y agoThis 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?
- agconti 10y agoThe sites down, here's the cached version: 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 http://webcache.googleusercontent.com/search?q=cache:5fXNOBY...
- Klathmon 10y agoThis 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?
- bananaoomarang 10y agoI think the biggest factor here is the HN front page is the same for everyone, Reddit’s often depends on what subreddit’s you subscribe to (AFAIK). + Most of my time on Reddit is specific (small-ish) subreddits, vs. HN where you can basically just look at the front page.
- Klathmon 10y agoI guess, but I've had a site I own get to the front page of a default sub on reddit, and it's impressive to say the least. With the multiple-magnitude less comments and votes that HN submissions get, I can't imagine they can get anywhere near that unless HN has a LOT more non-contributing types.
- SomeCallMeTim 10y agoDynamically generated sites are a Bad Idea when they can be trivially statically generated. A lot of people still think using WordPress or even Rails for site generation is fine, but both are hard to scale. And if the site is small or academic, it will fall over with not too much traffic. I wrote a rant [1] about this a couple of weeks ago. I can guarantee that my site will never have a "Database Connection Failed" error (now), because there's no database backing it. Even better would be if I moved hosting to S3/CloudFront. Dirt cheap, and Amazon isn't going to fall over even if a site hits Reddit's front page. I might not like the bill I get at the end of the month if it really goes crazy, though. [1] https://realmensch.org/2016/11/22/drupal-is-dead-long-live-static-site-generation/ https://realmensch.org/2016/11/22/drupal-is-dead-long-live-s...
- n0us 10y agoI always thought their documentation was excellent tbh.
- alexhayes 10y agoI 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 10y agoGoing to echo this, really hard to read, both because of the color palette and the bizarre white spacing between the black lines of code.
- pimlottc 10y agoFor me, it's the giant header that takes up a quarter of the page height (at least if you don't have a rather wide page width).
- diegorbaquero 10y agoGreat 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.
- deleted 10y ago[deleted]
- garysieling 10y agoThere is a similar library (seamless-immutable) that skips freezing objects in the production mode, so you can get the best of both worlds.
- victorcase 10y ago@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.
- seattle_spring 10y agoImmutable.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 10y agoWhich 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 10y agoYou might dig mudash – Lodash wrapper providing immutable.js support https://github.com/brianneisler/mudash https://github.com/brianneisler/mudash
- shados 10y agoThat'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.
- ht85 10y agoI'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.
- Illniyar 10y agoI 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 10y agoseamless 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".
- Waterluvian 10y agoAye. I found its interface to be simpler but it quickly became clear that it was fundamentally useless since I lost the performance gains of partial mutations that left unmutated parts of the structure with the same reference.
- Illniyar 10y agoWhat 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 10y agoThe 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 10y agoAnd immutable.jsdoes that?
- SomeCallMeTim 10y agoFirst, 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 10y agoI 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 10y ago>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. :)
- BinaryIdiot 10y agoI'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 10y agoThe 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 10y ago> 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.
- 10y ago