Use production mode for React that strips out all the warnings

[vjeux]

This benchmark is using the dev mode of React which enables a lot of developer warnings and is not meant to be used in production because it is way slower. This pull request enables production mode and the perf is totally different.

I bumped the number of games to 500 in both React and Vue and this is what the traces look like:

React:

Vue:

[Willmo36]

Shit that's a big difference. I'll re-run the tests on the same computer tomorrow. Cheers for this!

[vjeux]

You should also add a minification pass which also seems to improve the benchmark a bit too

new webpack.optimize.UglifyJsPlugin({}),

[jaygarcia]

Shiiiiiiiiiit. Such a simple change made that big of an effect. wow.

[yyx990803]

Just want to chime in here - I was running the two versions locally and it seems the React version is doing way fewer actual updates than the Vue version, because the update delay is different:

VueReactPerf/src/react.data.js

Line 20 in 1d83fcd

return i === 0 ? $ : $.delay(delay * 1000);

VueReactPerf/src/vue.data.js

Line 36 in 1d83fcd

return i === 0 ? $ : $.delay(delay * 100);

(links above are from the commit before merging the PR that fixed this)

Basically the Vue version is doing 10 times the work than the React version?... ouch

[yyx990803]

And this is after adjusting the delay in the Vue version to 1000ms (same as React's), item count to 500, running over 15s, in production mode for both React and Vue:

Vue

React

[yyx990803]

And, if you decrease the delay to 100ms for both, the perf difference is much more obvious too:

Vue

React

[gschambers]

Some really great insights. Thank you @vjeux and @yyx990803 for catching these two major bugs with the tests. We'll rerun and update our findings.

[pluma]

I'm not sure whether this is relevant for the benchmark but the current "best practice" in React seems to be to also use these two babel transforms when running in production for additional performance optimization:

• https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-react-constant-elements
• https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-react-inline-elements

(see also https://github.com/thejameskyle/babel-react-optimize)

EDIT: also allegedly pure functional components are faster than class components, I think? Not sure what relative impact this has.

[gaearon]

EDIT: also allegedly pure functional components are faster than class components, I think? Not sure what relative impact this has.

No, this is incorrect, they’re not. (And they’re slower than class components with shouldComponentUpdate.)

[pocketjoso]

No, this is incorrect, they’re not.

Not yet? :)

[export-mike]

@pocketjoso use functional components sure, but decorate them with HOC that give you a shouldComponentUpdate shallow diff and get best of both worlds.

import pure from 'recompose/pure';
const MyFunctionalComponent => props => <h1>props.message</h1>;
export default pure(MyFunctionalComponent);

[pluma]

@gaearon Thanks for clarifying. I only remembered this quote from Ben Alpert:

In the future, we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations.

Is that still on the roadmap?

[pocketjoso]

@export-mike I use connect from react-redux which essentially for this purpose does the same thing.
(But I had not seen recompose before - looks very useful so thanks for sharing!)

[export-mike]

@pocketjoso connect just provides a shouldComponentUpdate function to your container component so that'll be ok, to get better performance add this to all components so thats containers and presentational components.

[export-mike]

a bit of background @pocketjoso I discovered it from this message @gaearon added to the unmaintained PureComponent https://github.com/gaearon/react-pure-render

[gaearon]

Is that still on the roadmap?

Eventually, yea. I would say no earlier than facebook/react#6170 becomes a real thing.

[gschambers]

Thanks for all the great feedback - we've posted some updated results here: https://engineering.footballradar.com/a-fairer-vue-of-react-comparing-react-to-vue-for-dynamic-tabular-data-part-2/

[gorioli]

Question:

After all of the comparison is done, would you consider to switch to Vue from React, or at least implement the new projects with Vue?

I am asking, because Vue does seem to be better for the particular case where a tabular data is changing frequently. This case suggests to use Rx with React, since we want to handle the data reactively.

For other cases, where we do not have observable data, the performance difference would not apparently be so noticeable. Developers, as all humans, have preferences which means if one likes React's semantic more than Vue's, would it be reasonable for him to stick to React despite the fact that Vue outperforms React in particular cases.

Also, React community is bigger so we have more React based libraries for common tasks and nice integration with webpack and redux for example (not sure if they are easily integrated with Vue as well).
In short, I am curious what are your personal choices regarding wether you will be using Vue in your future/current projects or not.

Would be nice to see how simulacra performs in the same context.

Thank you for the great post btw!

[gerard-pmh]

vue-cli gives you a great integration of vue with webpack or browserify.