8 ms·

This is really interesting. In the summer of last year, I was looking into various JS libraries to use for an upcoming project at work when I saw the story that

• jordwalke 12y ago
  (I'm on the ReactJS team at Facebook) >> pathological case for something like React. The is absolutely likely to be the case (for now). I admit I haven't looked into the technical issues very much because I've been spending 100% my time on ReactNative which seeks to resolve the deepest issues with the browser environment for React development - it's certainly a different kind of performance work. For this kind of stuff, most people create a highly custom React base class that "cuts right to the chase" as far as updating small pieces that change in large lists. Immutable data structures are often the most helpful tool in accomplishing that. I'm sure they have totally legitimate reasons to go with this approach in the mean time, and most of all I want their project Atom to succeed because it's such a great idea. I hope we can help the Atom team soon to resolve these other issues though.
  • seanmcdirmid 12y ago
    > Immutable data structures are often the most helpful tool in accomplishing that. This is said often but without much qualification. I've found mutable data structures with change propagation (via observable or what not) to work much better given that the whole diffing thing can be avoided altogether since you know exactly what has changed. It is my understanding that the DOM is broken in how it handles invalidation/re-rendering (doing it for each modification rather than batching), but again, I don't see how immutability helps fix that problem any better than just doing it the right way with a mutable virtual DOM?
    • vjeux 12y ago
      Highly recommend watching Lee Byron talk about immutability. He covers your doubts very well. http://conf.reactjs.com/schedule.html#immutable-data-and-react http://conf.reactjs.com/schedule.html#immutable-data-and-rea...
      • seanmcdirmid 12y ago
        > Immutable data unlocks powerful memoization techniques and prohibits accidental coupling via shared mutable state. Memoization is still more expensive than just tracking changes and avoiding unnecessary recomputations directly (it only starts winning when doing dynamic programming). There is a point on accidental coupling but this is more of a correctness rather than performance issue. In the high-performance computing field, use of immutable data structures is suicidal; even tries are a magnitude slower than in-place mutable data structures. And he only compares against naked shared mutable state, not against managed mutable state with change propagation. And that gets to the end of the talk: the real reason is they want to avoid using frameworks that already solve this problem by tracking changes, and React somehow avoids that since you can do just the diff post facto. Ok, I get that.
        • moomin 12y ago
          Yes, but immutability means that reference checks are enough to spot unchanged areas. And we're not in HPC land right now, we're writing JavaScript. In that world, Om (immutable) is vastly faster than Backbone, Knockout, Angular, Ember &c (mutable). Partially because, when you can reason more clearly, it's easier to do something about the performance.
          • seanmcdirmid 12y ago
            Reference checks are conservative in spotting unchanged areas (if true, definitely no change, if false, maybe no change) unless all values are internalized (a bit expensive to do that). Also, diffing is only needed at all when you need to compare values anyways; dirty bits are otherwise sufficient to mark changes. I'm not really familiar with the web ecosystem, but why would it differ so much from say C#/WPF? or a system based on change propagation instead of diffing?
  • crazychrome 12y ago
    One question: when can we have a real look at react-native ?