5 ms·

Hey, I'm the author of this library. It's definitely inspired by mori (and clojure and Haskell) and the reason I ended up building something different was to pr

Hey, I'm the author of this library. It's definitely inspired by mori (and clojure and Haskell) and the reason I ended up building something different was to present a more JavaScript friendly API (and academically, to learn about HAMT). I've built this over the last couple weeks, and we are not using it internally yet - but I wanted to ensure development of it happened in public.

dahjelle 12y ago
Thanks—this looks pretty exciting! I've been using Mori, but this appears to have a more JS-ish API. Can you give some other comparisons to Mori (i.e. feature set, performance, etc.)?
- leebyron 12y ago
  The feature set is comparable sans yet to come SortedSet and SortedMap (aka Red Black Tree). Performance should also be comparable if not slightly faster than mori in some iteration cases, as it's tuned for JS instead of ClojureScript and I've forgone some of the functional purity for speed. But this is anecdotal and I don't have any perf tests yet.
  - moomin 12y ago
    I think you might be surprised exactly what running code through an optimising compiler achieves.
    - taeric 12y ago
      I'm curious at what you are hinting at here. Especially when you are discussing the data structure, I've not seen too much magic that an optimizing compiler can really achieve. That is, the compilers are usually more geared to help speed up the code, not so much the data. Any good links showing otherwise?
- swannodette 12y ago
  First off it's very exciting and cool to see a company like Facebook release an open source persistent data structure library for JavaScript. Mori just has more stuff and the benefit of 3 years of development and production use. This becomes quite apparent on the metrics you asked about: - mori is a 32K gzipped browser dependency, tons of helpers functions - immutable-js is a 10K gzipped browser dependency (with Uglify and aggressive mangling), mostly just data structures ClojureScript (and thus Mori) has been continuously tuned for 3 different major JS engines - JavaScriptCore, V8, and SpiderMonkey. Running some basic benchmarks overall Mori comes out ahead on most operations. But there's nothing surprising here, immutable-js is brand spanking new :). Also there are micro-optimizations (which add up) in ClojureScript that are impossible to expose to JS users w/o a compiler. In anycase this is great stuff and I'm excited to see how JavaScript and more specifically React devs leverage these to explore the ideas currently be played around with in ClojureScript/Om/Elm/etc.
  - grayrest 12y ago
    I've run across a couple HAMT implementations you might not have seen: https://github.com/mattbierner/hamt/ https://github.com/mattbierner/hamt/ https://github.com/Tvaroh/moreartyjs https://github.com/Tvaroh/moreartyjs The first implementation (hamt) is interesting because it's in a same semantics compile-to-js language (by the author) called Khepri and it benchmarks pretty well on datastructure microbenchmarks. http://khepri-lang.com/ http://khepri-lang.com/ https://github.com/mattbierner/js-hashtrie-benchmark https://github.com/mattbierner/js-hashtrie-benchmark The second is a less interesting pure JS implementation that I show as faster than mori and slower than hamt on the hashtrie-benchmark. I've been meaning to test them on a wider variety of benchmarks (more aggregate operations and vs transients) but I only ran across them last week and I've been busy.
    - swannodette 12y ago
      Thanks for the links. Sadly doing mori benchmarks like this does't say as much about the performance of ClojureScript data structures than it does about mori specifically - in many cases you are likely just benchmarking multi-arity function dispatch overhead because you don't have the ClojureScript compiler doing direct dispatch for you. If you want accurate benchmarking of ClojureScript data structures you will need to write the benchmark in ClojureScript for the time being and call them from JavaScript. Also benchmarking in Node.js doesn't reflect the wide variance you find in JS engines. In several cases in the past we avoided V8 specific optimizations because it punished other JS engines. UPDATE: I also ran some benchmarks and I can't replicate the perf degradation as the size of the hash map increases. My suspicion is that the random key generation may result in many hash collisions w/ Murmur3 which would explain the dramatic perf degradation which is unlikely to occur in the wild.
ionforce 12y ago
What is HMAT?
- colinramsay 12y ago
  Hash array mapped trie: http://en.wikipedia.org/wiki/Hash_array_mapped_trie http://en.wikipedia.org/wiki/Hash_array_mapped_trie
- leebyron 12y ago
  It would help if I could spell. Fixed the typo and: http://en.m.wikipedia.org/wiki/Hash_array_mapped_trie http://en.m.wikipedia.org/wiki/Hash_array_mapped_trie
dustingetz 12y ago
does facebook intend to use this internally? The code is (C) Facebook, so Facebook is at least interested enough to pay for the development, right? or is this just some sort of R&D that won't have near term impact at facebook?
tiglionabbit 12y ago
How's the performance on the immutable vectors? I wrote an immutable vector library once, but it turned out impractical to do game physics with because it was too slow. Switching to self-modifying vectors fixed the problem. I think the performance hit of allocating new JS objects might be too high for games.
fnordsensei 12y ago
A question: how influential has Swanodette's work with ClojureScript/Om in relation to React been to the direction that you (yourself and Facebook) are taking the evolution of React and its supporting libraries in? From what I've seen, I'm guessing: quite a bit, but I'm not sure that I've noticed it being mentioned. In particular, I'm guessing that the performance characteristics of Om might be especially inspiring. Edit: Oh, and good work on the library! It's great to see efforts to make the case of immutability within the world of JS.
- leebyron 12y ago
  Personally, a good amount! I know a lot of the React team are also big fans of Om. React has always been inspired by functional programming and I think in another universe we would have preferred to write it in Scala or Haskell or Clojure. With React (and this Immutable lib) we've been trying to incorporate ideas of functional programming into JavaScript product while still feeling familiar and "native to JS".
- chenglou 12y ago
  I contribute to React. I'm definitely a big fan of ClojureScript and I borrow ideas from it when I can. I currently have a few crazy ideas that are direct results of looking into the Clojure (or Haskell) ecosystem and finding that they've solved my problems, but better. In general, some of the problems we face, at language/library/ecosystem level, might simply not exist in these languages. It's a shame they're not more popular. Regarding popularity, I feel that sometimes the web development community can be ironically dogmatic, considering that it's a free and open platform (see: HN/Reddit's initial reaction to React). Looking back, I still find it incredible that React actually gained so much traction when it defies so many of the pre-established "best practices". I think lots of people, including me, are learning more and more to take a step back before dismissing an idea. So if you were one of those that dismissed Clojure/ClojureScript because "parentheses in front of my function call?", "snake case isn't for me", or "it's too different from idiomatic js" (I hope this one isn't too much of a strawman here), then I urge you to give it another try. Learning React doesn't have to be the only time you open your mind to new ideas and reconsider best practices.
lidingpku 12y ago
I just read through the discussion, and created an "awesome style" note on GitHub based on the resources mentioned. Did I miss anything? https://github.com/memect/awesomeport/blob/master/awesome/immutable-js.md https://github.com/memect/awesomeport/blob/master/awesome/im...

dahjelle 12y ago

Thanks—this looks pretty exciting! I've been using Mori, but this appears to have a more JS-ish API. Can you give some other comparisons to Mori (i.e. feature set, performance, etc.)?

leebyron 12y ago
The feature set is comparable sans yet to come SortedSet and SortedMap (aka Red Black Tree). Performance should also be comparable if not slightly faster than mori in some iteration cases, as it's tuned for JS instead of ClojureScript and I've forgone some of the functional purity for speed. But this is anecdotal and I don't have any perf tests yet.
- moomin 12y ago
  I think you might be surprised exactly what running code through an optimising compiler achieves.
  - taeric 12y ago
    I'm curious at what you are hinting at here. Especially when you are discussing the data structure, I've not seen too much magic that an optimizing compiler can really achieve. That is, the compilers are usually more geared to help speed up the code, not so much the data. Any good links showing otherwise?
swannodette 12y ago
First off it's very exciting and cool to see a company like Facebook release an open source persistent data structure library for JavaScript. Mori just has more stuff and the benefit of 3 years of development and production use. This becomes quite apparent on the metrics you asked about: - mori is a 32K gzipped browser dependency, tons of helpers functions - immutable-js is a 10K gzipped browser dependency (with Uglify and aggressive mangling), mostly just data structures ClojureScript (and thus Mori) has been continuously tuned for 3 different major JS engines - JavaScriptCore, V8, and SpiderMonkey. Running some basic benchmarks overall Mori comes out ahead on most operations. But there's nothing surprising here, immutable-js is brand spanking new :). Also there are micro-optimizations (which add up) in ClojureScript that are impossible to expose to JS users w/o a compiler. In anycase this is great stuff and I'm excited to see how JavaScript and more specifically React devs leverage these to explore the ideas currently be played around with in ClojureScript/Om/Elm/etc.
- grayrest 12y ago
  I've run across a couple HAMT implementations you might not have seen: https://github.com/mattbierner/hamt/ https://github.com/mattbierner/hamt/ https://github.com/Tvaroh/moreartyjs https://github.com/Tvaroh/moreartyjs The first implementation (hamt) is interesting because it's in a same semantics compile-to-js language (by the author) called Khepri and it benchmarks pretty well on datastructure microbenchmarks. http://khepri-lang.com/ http://khepri-lang.com/ https://github.com/mattbierner/js-hashtrie-benchmark https://github.com/mattbierner/js-hashtrie-benchmark The second is a less interesting pure JS implementation that I show as faster than mori and slower than hamt on the hashtrie-benchmark. I've been meaning to test them on a wider variety of benchmarks (more aggregate operations and vs transients) but I only ran across them last week and I've been busy.
  - swannodette 12y ago
    Thanks for the links. Sadly doing mori benchmarks like this does't say as much about the performance of ClojureScript data structures than it does about mori specifically - in many cases you are likely just benchmarking multi-arity function dispatch overhead because you don't have the ClojureScript compiler doing direct dispatch for you. If you want accurate benchmarking of ClojureScript data structures you will need to write the benchmark in ClojureScript for the time being and call them from JavaScript. Also benchmarking in Node.js doesn't reflect the wide variance you find in JS engines. In several cases in the past we avoided V8 specific optimizations because it punished other JS engines. UPDATE: I also ran some benchmarks and I can't replicate the perf degradation as the size of the hash map increases. My suspicion is that the random key generation may result in many hash collisions w/ Murmur3 which would explain the dramatic perf degradation which is unlikely to occur in the wild.

ionforce 12y ago

What is HMAT?

colinramsay 12y ago
Hash array mapped trie: http://en.wikipedia.org/wiki/Hash_array_mapped_trie http://en.wikipedia.org/wiki/Hash_array_mapped_trie
leebyron 12y ago
It would help if I could spell. Fixed the typo and: http://en.m.wikipedia.org/wiki/Hash_array_mapped_trie http://en.m.wikipedia.org/wiki/Hash_array_mapped_trie

dustingetz 12y ago

does facebook intend to use this internally? The code is (C) Facebook, so Facebook is at least interested enough to pay for the development, right? or is this just some sort of R&D that won't have near term impact at facebook?

tiglionabbit 12y ago

How's the performance on the immutable vectors? I wrote an immutable vector library once, but it turned out impractical to do game physics with because it was too slow. Switching to self-modifying vectors fixed the problem. I think the performance hit of allocating new JS objects might be too high for games.

fnordsensei 12y ago

A question: how influential has Swanodette's work with ClojureScript/Om in relation to React been to the direction that you (yourself and Facebook) are taking the evolution of React and its supporting libraries in? From what I've seen, I'm guessing: quite a bit, but I'm not sure that I've noticed it being mentioned. In particular, I'm guessing that the performance characteristics of Om might be especially inspiring. Edit: Oh, and good work on the library! It's great to see efforts to make the case of immutability within the world of JS.

leebyron 12y ago
Personally, a good amount! I know a lot of the React team are also big fans of Om. React has always been inspired by functional programming and I think in another universe we would have preferred to write it in Scala or Haskell or Clojure. With React (and this Immutable lib) we've been trying to incorporate ideas of functional programming into JavaScript product while still feeling familiar and "native to JS".
chenglou 12y ago
I contribute to React. I'm definitely a big fan of ClojureScript and I borrow ideas from it when I can. I currently have a few crazy ideas that are direct results of looking into the Clojure (or Haskell) ecosystem and finding that they've solved my problems, but better. In general, some of the problems we face, at language/library/ecosystem level, might simply not exist in these languages. It's a shame they're not more popular. Regarding popularity, I feel that sometimes the web development community can be ironically dogmatic, considering that it's a free and open platform (see: HN/Reddit's initial reaction to React). Looking back, I still find it incredible that React actually gained so much traction when it defies so many of the pre-established "best practices". I think lots of people, including me, are learning more and more to take a step back before dismissing an idea. So if you were one of those that dismissed Clojure/ClojureScript because "parentheses in front of my function call?", "snake case isn't for me", or "it's too different from idiomatic js" (I hope this one isn't too much of a strawman here), then I urge you to give it another try. Learning React doesn't have to be the only time you open your mind to new ideas and reconsider best practices.

lidingpku 12y ago

I just read through the discussion, and created an "awesome style" note on GitHub based on the resources mentioned. Did I miss anything? https://github.com/memect/awesomeport/blob/master/awesome/immutable-js.md https://github.com/memect/awesomeport/blob/master/awesome/im...