Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Immutable data structures make React's diffing algorithm really smart.

I was very intrigued when I heard this claimed in a blog article a while back. So I investigated this claim deeply and was not entirely convinced. For example, the immutable approach to tree diffing actually requires more work in some cases, since you always have to diff from the root.

I wrote more about this here: http://blog.reverberate.org/2014/02/on-future-of-javascript-...



This actually isn't true anymore that you always have to render from the root in Om. We've already changed component local state to avoid this, and likely in the near future this will be true in the props case as well.


Thanks for the update -- could you explain how this works? Do you figure out internally-to-Om which subtrees have actually changed and call setState() and/or forceUpdate() on them?

The original article said that Om doesn't use setState() at all -- has this changed?


"Om is an immutable data structure library"

The immutable data structures come from clojurescript, all the default data structures in clojure/clojurescript are immutable.

Om is react.js bindings for clojurescript and some state management functionality.

You can't blame me for disregarding everything after that mistake can you? It casts quite a bit of doubt on "I investigated this claim deeply".


If you see any factual inaccuracies in the substance of my conclusions, please let me know (for example, swannodette's updated information in a sibling comment is very useful). I will update my article to correct the distinction you mentioned.

> You can't blame me for disregarding everything after that mistake can you?

Yes, I think it's unreasonable and uncharitable. Any nontrivial piece of work is going to have mistakes. I was investigating a set of technologies that were totally new to me (React, ClojureScript, Om) and I had no friends who were experts in the subject matter to review the article for me prior to publishing it. Given that, I think I did a pretty good job actually. The mistake you mention has no impact on the article's conclusions.

My article was not attacking or argumentative, but a good-faith attempt to understand the prior article's claims better.


I also didn't mean that as an attack, disregard was probably the wrong word to use.

I meant that since it is indeed a non-trivial piece of work and the performance characteristics in question are very complex and depend quite strongly on the Clojure state model then it's reasonable to assume your conclusions are wrong because of the mistake made at the start of your chain of reasoning.

For example: "And it is hard to imagine convenient two-way data binding being built on top of immutable data structures." makes perfect sense if you are working in javascript, but is a normal and elegant way of doing things in clojurescript (and the cursor implementation in Om makes them incredibly convenient).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: