10 ms·

My first thought when looking at the benchmarks is that I find it strange that Backbone is faster than React. Not that I imagine Backbone to be slow, particular

My first thought when looking at the benchmarks is that I find it strange that Backbone is faster than React. Not that I imagine Backbone to be slow, particularly, just that this article is about one of React's key features - the virtual DOM - and that's something which Backbone doesn't have. I'd expect to see React up there with Om, Mercury & Elm. I've just had a look at the code and React is using a localstorage backend, while Backbone is using its models + collections with a localstorage extension... so I'd expect there to at least be some overhead there, but apparently not. Does anyone have any quick thoughts on what might be happening here? I can't shake the feeling that these benchmarks might not be terribly useful.

pestaa 12y ago
I've seen some AngularJS vs React benchmarks a while back. I believe it was http://jsperf.com/angular-vs-react/5 http://jsperf.com/angular-vs-react/5 I consistently got the result of Angular utterly and completely destroying React. Initially I blamed the virtual DOM approach, but after seeing other frameworks utilizing it and outperforming Angular by a huge margin, it seems to me that React is not written for performing well on small DOM documents. (There might be a turning point, considering how bloated Facebook pages it was designed for.)
- syntern 12y ago
  Our performance benchmarks suggest that application performance is most certainly better off with: (a) DOM reuse (b) calculating expensive things only once (c) reducing GC pressure == not discarding/recreating things (d) coordinating actions that may trigger reflow. It is independent of what framework you are using. My limited understanding of React is that it fails in (a), (b) and (c), and only limited measures can be applied to improve them. Re-creating the entire DOM on each update probably does not help. I have no information if (d) is possible with it. I am using Angular.dart for a while now, and it can be used to get all of them in an optimal way. Disclaimer: I'm working at Google.
  - kaonashi 12y ago
    > Re-creating the entire DOM on each update probably does not help Perhaps you meant virtual DOM here? (in any case, the actual DOM is not recreated on every update)
  - mudetroit 12y ago
    React can handle all of your items just fine depending upon usage. (a) Using the key property, will give React a manner to determine likeness of elements (b) Don't calculate the expensive things at render time, do them when loading or modifying state. (c) Is related to a, but I haven't run into large problems with this personally. (d) React does batch changes to an extent I believe.
  - underwater 12y ago
    None of the things you have guessed about React are true.
  - sisk 12y ago
    All of those points are precisely what React addresses. The virtual DOM determines which mutations are necessary and performs only those, batched. It also reuses DOM nodes as appropriate. DOM nodes can even be keyed against data in the case that, between transitions, it isn't entirely clear which nodes correspond to which data.
  - vjeux 12y ago
    (a) You can use the key attribute in order to get DOM reuse. If you are looping over N keys then React is going to reuse the nodes and move them around. (b) You can implement shouldComponentUpdate in order to have a quick way not to re-render a sub-tree if nothing changed. (c) See (b) but we're also working on changing the internal representation of the virtual DOM to plain js objects that can be reused[1]. We were super worried about GC but it turns out that it hasn't been the bottleneck yet for our use cases. (d) If you are writing pure React, all the actions are batched and actually, it's write-only, React almost never reads from the DOM. If you really need to read, you can do it in componentWillUpdate and write in componentDidUpdate. This will coordinate all the reads and write properly. A really important part of React is that by default this is reasonably fast, but most importantly, when you have bottlenecks, you can improve performance without having to do drastic architecture changes. (1) You can implement shouldComponentUpdate at specific points and get huge speedup. We've released a perf tool that tells you where are the most impactful places to[2]. If you are bold, you can go the route of using immutable data structures all over the place like Om/the elm example and you're not going to have to worry about it. (2) At any point in time, you can skip React and go back to raw DOM operations for performance critical components. This is what Atom is doing and the rest of their UI is pure React. [1] https://github.com/reactjs/react-future/blob/master/01%20-%20Core/05%20-%20Descriptors.js https://github.com/reactjs/react-future/blob/master/01%20-%2... [2] http://facebook.github.io/react/docs/perf.html#perf.printwastedmeasurements http://facebook.github.io/react/docs/perf.html#perf.printwas...
- kaonashi 12y ago
  That benchmark confuses me; is it measuring the entire run of that script, i.e. is it measuring the setup (creating class, inserting into dom) on every run? If so that seems like the wrong way to go about testing performance.
mudetroit 12y ago
It's worth noting that Om uses React internally[1]. React, like almost every tool out there, can work very well when used appropriately, or poorly if use in appropriately. [1] http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc...
asolove 12y ago
(Edit: posted this comment before I read the article, doh.) These is certainly something wrong with the benchmark. Since Om is a layer on top of React, it is obvious that React itself cannot be necessarily slower than Om. (Perhaps idiomatic React usage is slower than idiomatic Om usage for this case, though?)
- matchu 12y ago
  See the article's discussion of immutability in Elm. Om has the same immutability property, so configures React to take advantage of that property, skipping vanilla React's property diffing. edit: Rather, see masklinn's comment that describes what actually happens. Point being, vanilla React does extra work to account for anything a developer might do, but allows Elm and Om, which have more rigorous standards for their users, to override that behavior.
  - masklinn 12y ago
    Vanilla React doesn't do property diffing by default, it re-renders the whole tree then diffs the whole virtual DOM, because it can't rely on data immutability or on components purity. Since Om or Elm assume immutable inputs and pure components they can skip rendering components altogether when the inputs have not changed (mentioned in TFA's "Making Virtual DOM Fast"). React can do that, but it has to be opted in component by component either by using PureRenderMixin or by implementing shouldComponentUpdate.
    - matchu 12y ago
      Gotcha—I'd assumed property diffing was the way to go because it hadn't occurred to me that folks would be writing impure components. Thanks!
masklinn 12y ago
> I'd expect to see React up there with Om, Mercury & Elm. Not by default because it's missing laziness and immutability: because just about everything in javascript is mutable, React can't prune out the changeset as the developers could be modifying the application state behind its back in ways unknown (or worse, could be using state which is not under React's control, neither props nor state, but globals and stuff). That is, for safety/correctness reasons the default `shouldComponentUpdate` is `function () { return true; }`. The result is React has to re-render the whole virtual DOM tree (by default) and the only possible gain is when diffing the real and virtual trees. Because Clojurescript and Elm are based on immutable structures they can take the opposite default (and if you're going behind their back and mutating stuff it's your problem). Also, I'm not sure React defers rendering until animationFrame. An optimized React application (or at least one which uses PureRenderMixin[0]) ought have closer performances to the others's (Om is a bunch of abstractions over React after all, so you should be able to have at least as good performances in pure React as you get in Om). [0] http://facebook.github.io/react/docs/pure-render-mixin.html http://facebook.github.io/react/docs/pure-render-mixin.html
grayrest 12y ago
Without looking at the benchmark code: * Development React is slower than production React. There are a bunch of extra checks all over the place along with a profiler [1]. [1] http://facebook.github.io/react/docs/perf.html http://facebook.github.io/react/docs/perf.html * Speed isn't the top priority of the framework, predictability is. There's a virtual event infrastructure and other browser normalization work going on. Om is using React under the hood and more or less represents the best case scenario. * React isn't magically fast. The diff process still has to visit all the nodes in the virtual DOM, generate the edit list, and apply it, which is a substantial amount of overhead. I'm used to seeing React even or behind when benchmarked with a small number of nodes. The explanation I've seen is that these benchmarks aren't considered important since the goal isn't to be as fast as possible but rather to never be slower than 16ms. The trick behind most of the "React is fast" articles is that React is O(N_dom) instead of O(N_model) so if you can shrink the size of the output DOM, React goes faster. The Om line demonstrates this and doing screen-sized render over a sliding window of data in a huge data set (most grid/scrolling list demos) is another common example. There are perf knobs that probably aren't being turned here but if the app renders fast enough why would you waste your time turning them?

pestaa 12y ago

I've seen some AngularJS vs React benchmarks a while back. I believe it was http://jsperf.com/angular-vs-react/5 http://jsperf.com/angular-vs-react/5 I consistently got the result of Angular utterly and completely destroying React. Initially I blamed the virtual DOM approach, but after seeing other frameworks utilizing it and outperforming Angular by a huge margin, it seems to me that React is not written for performing well on small DOM documents. (There might be a turning point, considering how bloated Facebook pages it was designed for.)

syntern 12y ago
Our performance benchmarks suggest that application performance is most certainly better off with: (a) DOM reuse (b) calculating expensive things only once (c) reducing GC pressure == not discarding/recreating things (d) coordinating actions that may trigger reflow. It is independent of what framework you are using. My limited understanding of React is that it fails in (a), (b) and (c), and only limited measures can be applied to improve them. Re-creating the entire DOM on each update probably does not help. I have no information if (d) is possible with it. I am using Angular.dart for a while now, and it can be used to get all of them in an optimal way. Disclaimer: I'm working at Google.
- kaonashi 12y ago
  > Re-creating the entire DOM on each update probably does not help Perhaps you meant virtual DOM here? (in any case, the actual DOM is not recreated on every update)
- mudetroit 12y ago
  React can handle all of your items just fine depending upon usage. (a) Using the key property, will give React a manner to determine likeness of elements (b) Don't calculate the expensive things at render time, do them when loading or modifying state. (c) Is related to a, but I haven't run into large problems with this personally. (d) React does batch changes to an extent I believe.
- underwater 12y ago
  None of the things you have guessed about React are true.
- sisk 12y ago
  All of those points are precisely what React addresses. The virtual DOM determines which mutations are necessary and performs only those, batched. It also reuses DOM nodes as appropriate. DOM nodes can even be keyed against data in the case that, between transitions, it isn't entirely clear which nodes correspond to which data.
- vjeux 12y ago
  (a) You can use the key attribute in order to get DOM reuse. If you are looping over N keys then React is going to reuse the nodes and move them around. (b) You can implement shouldComponentUpdate in order to have a quick way not to re-render a sub-tree if nothing changed. (c) See (b) but we're also working on changing the internal representation of the virtual DOM to plain js objects that can be reused[1]. We were super worried about GC but it turns out that it hasn't been the bottleneck yet for our use cases. (d) If you are writing pure React, all the actions are batched and actually, it's write-only, React almost never reads from the DOM. If you really need to read, you can do it in componentWillUpdate and write in componentDidUpdate. This will coordinate all the reads and write properly. A really important part of React is that by default this is reasonably fast, but most importantly, when you have bottlenecks, you can improve performance without having to do drastic architecture changes. (1) You can implement shouldComponentUpdate at specific points and get huge speedup. We've released a perf tool that tells you where are the most impactful places to[2]. If you are bold, you can go the route of using immutable data structures all over the place like Om/the elm example and you're not going to have to worry about it. (2) At any point in time, you can skip React and go back to raw DOM operations for performance critical components. This is what Atom is doing and the rest of their UI is pure React. [1] https://github.com/reactjs/react-future/blob/master/01%20-%20Core/05%20-%20Descriptors.js https://github.com/reactjs/react-future/blob/master/01%20-%2... [2] http://facebook.github.io/react/docs/perf.html#perf.printwastedmeasurements http://facebook.github.io/react/docs/perf.html#perf.printwas...
kaonashi 12y ago
That benchmark confuses me; is it measuring the entire run of that script, i.e. is it measuring the setup (creating class, inserting into dom) on every run? If so that seems like the wrong way to go about testing performance.

mudetroit 12y ago

It's worth noting that Om uses React internally[1]. React, like almost every tool out there, can work very well when used appropriately, or poorly if use in appropriately. [1] http://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ http://swannodette.github.io/2013/12/17/the-future-of-javasc...

asolove 12y ago

(Edit: posted this comment before I read the article, doh.) These is certainly something wrong with the benchmark. Since Om is a layer on top of React, it is obvious that React itself cannot be necessarily slower than Om. (Perhaps idiomatic React usage is slower than idiomatic Om usage for this case, though?)

matchu 12y ago
See the article's discussion of immutability in Elm. Om has the same immutability property, so configures React to take advantage of that property, skipping vanilla React's property diffing. edit: Rather, see masklinn's comment that describes what actually happens. Point being, vanilla React does extra work to account for anything a developer might do, but allows Elm and Om, which have more rigorous standards for their users, to override that behavior.
- masklinn 12y ago
  Vanilla React doesn't do property diffing by default, it re-renders the whole tree then diffs the whole virtual DOM, because it can't rely on data immutability or on components purity. Since Om or Elm assume immutable inputs and pure components they can skip rendering components altogether when the inputs have not changed (mentioned in TFA's "Making Virtual DOM Fast"). React can do that, but it has to be opted in component by component either by using PureRenderMixin or by implementing shouldComponentUpdate.
  - matchu 12y ago
    Gotcha—I'd assumed property diffing was the way to go because it hadn't occurred to me that folks would be writing impure components. Thanks!

masklinn 12y ago

> I'd expect to see React up there with Om, Mercury & Elm. Not by default because it's missing laziness and immutability: because just about everything in javascript is mutable, React can't prune out the changeset as the developers could be modifying the application state behind its back in ways unknown (or worse, could be using state which is not under React's control, neither props nor state, but globals and stuff). That is, for safety/correctness reasons the default `shouldComponentUpdate` is `function () { return true; }`. The result is React has to re-render the whole virtual DOM tree (by default) and the only possible gain is when diffing the real and virtual trees. Because Clojurescript and Elm are based on immutable structures they can take the opposite default (and if you're going behind their back and mutating stuff it's your problem). Also, I'm not sure React defers rendering until animationFrame. An optimized React application (or at least one which uses PureRenderMixin[0]) ought have closer performances to the others's (Om is a bunch of abstractions over React after all, so you should be able to have at least as good performances in pure React as you get in Om). [0] http://facebook.github.io/react/docs/pure-render-mixin.html http://facebook.github.io/react/docs/pure-render-mixin.html

grayrest 12y ago

Without looking at the benchmark code: * Development React is slower than production React. There are a bunch of extra checks all over the place along with a profiler [1]. [1] http://facebook.github.io/react/docs/perf.html http://facebook.github.io/react/docs/perf.html * Speed isn't the top priority of the framework, predictability is. There's a virtual event infrastructure and other browser normalization work going on. Om is using React under the hood and more or less represents the best case scenario. * React isn't magically fast. The diff process still has to visit all the nodes in the virtual DOM, generate the edit list, and apply it, which is a substantial amount of overhead. I'm used to seeing React even or behind when benchmarked with a small number of nodes. The explanation I've seen is that these benchmarks aren't considered important since the goal isn't to be as fast as possible but rather to never be slower than 16ms. The trick behind most of the "React is fast" articles is that React is O(N_dom) instead of O(N_model) so if you can shrink the size of the output DOM, React goes faster. The Om line demonstrates this and doing screen-sized render over a sliding window of data in a huge data set (most grid/scrolling list demos) is another common example. There are perf knobs that probably aren't being turned here but if the app renders fast enough why would you waste your time turning them?