
Comparing React to Vue for dynamic tabular data - maxwillmott
https://engineering.footballradar.com/from-a-react-point-of-vue-comparing-reactjs-to-vuejs-for-dynamic-tabular-data/
======
jhgg
At Discord we've actually spent a bit of time optimizing around frequently
updating tables of data.

On the extreme end of things, we have lists that contain several thousand
items that update a few elements that are potentially updating up to ten times
a second. The biggest being the member list on a server. One of our servers
has ~6500 online right now, with people coming online/offline/away every
second, changing their current game, typing, etc...

Few lessons we've learned: 1) Don't use ImmutableJS for small objects with a
few keys containing scalar values, it's too slow. It's actually faster to just
a) copy objects ({...oldValues, newKey: newValue}) or b) re-use objects and
power shouldComponentUpdate in another fashion. In some cases, we use an
"object version" that is incremented every time the object is actually
updated. Then compare that in shouldComponentUpdate. 2) Only render what's
visible. In our lists, each item has a fixed height, so we only render
elements that are visible. This cuts down from having to render 6500 items in
that list, to a good 20-30.

~~~
leebyron
Hey, author of Immutable.js here,

You're definitely right to point out that Immutable.js is really not always
what you want for small values that change all the time. Immutable.js
collections are best used for just that: collections. If you have to copy an
array or map with a ton of entries to make a change, it's going to be super
slow - Persistent Immutable data structures can help with that.

But I agree with your conclusion that any JS objects that are being used as
small tuples are definitely better off staying plain JS objects.

You also don't have to use all Immutable.js or nothing at all. Similar to how
using an ES6 Map collection means you don't have to stop using JS objects. Use
Immutable collections where they offer benefits, but spreading it everywhere
is not a performance panacea, as you rightly discovered.

~~~
jhgg
Love your work on Immutable.JS.

When I was typing out the original reply, I meant to say "Don't use
Immutable.JS for small objects" but ended up putting a period in the middle...
which could have led to some confusion. I've edited it to make it more clear.

We've also had some perf issues with using Immutable JS for even larger
arrays. I think paying the cost of shallow copying the entire array when
modifying it ended up winning in the long run as our render functions could
loop over the array much faster.

------
evan_
Using the production build of React changes the outcome significantly:

[https://github.com/footballradar/VueReactPerf/pull/3](https://github.com/footballradar/VueReactPerf/pull/3)

~~~
ckluis
fwiw - i love the quality of the screenshots and comments and the conversation
after that ensues after

~~~
ghayes
Christopher Chedeau (vjeux) is a core react contributor. It's cool that his
feedback was thoughtfully accounted for.

------
xgbi
A bit off-topic, but this is what my folder looks like after `npm install`:

    
    
      Dev du -h -d 1 VueReactPerf/
        1,2G    VueReactPerf/node_modules
        2,0M    VueReactPerf/dist
        52K    VueReactPerf/src
        1,7M    VueReactPerf/.git
        1,2G    VueReactPerf/
    

=> 1.2 GB of dependencies. What is happening to the JS ecosystem, where
displaying a table in HTML needs 1.2 freaking Gigabytes ?

~~~
petewailes
And this, children, is why we do a proper job. Because the JS landscape
nowadays looks like a house of cards, with people who can't code treating
modules like Lego to build things.

Web dev has exciting things going on in it, but it feels mostly like a bunch
of children with no concept of consequences running around desperately re-
inventing wheels, rather than caring about quality, efficiency, diligence and
professionalism.

It's fucking disgraceful, and we should be ashamed of it.

------
maxwillmott
I'd left React in development mode during these tests. See this PR
[https://github.com/footballradar/VueReactPerf/pull/3](https://github.com/footballradar/VueReactPerf/pull/3)
for some results with the issues fixed.

We'll re-run the tests in the morning (uk) and post the updates.

~~~
vjeux
You're unfortunately not the only one that doesn't use prod for doing
benchmarks and potentially also not for actual production. If you have ideas
on how we could better educate people about the difference, I'd love to know.
[https://twitter.com/Vjeux/status/735178192651063298](https://twitter.com/Vjeux/status/735178192651063298)

~~~
33degrees
I don't have any suggestions regarding education, but it would be helpful for
me (and I'm sure others) if there was a non minified production build
available via bower; My build process isn't using npm modules right now, so
I've been stuck using the dev version.

------
TheAceOfHearts
One of my coworkers wrote and maintains an amazing library called react-
virtualized [0], which can be of help for certain similar cases in which you
have to render huge amounts of data. You just avoid rendering anything outside
of the viewport.

[0] [https://bvaughn.github.io/react-
virtualized/](https://bvaughn.github.io/react-virtualized/)

~~~
netghost
Thanks for sharing that project. I've implemented similar things, and I have
to say, this seems to be very thoughtfully implemented.

------
bicknergseng
FWIW, the time spent in JS is only telling half the story. In that first
example, React spends half as much time painting and rendering as Vue; the DOM
diffing is more js-time intensive but results in less DOM thrashing.
Interesting to watch how poorly it seems to scale; I'm wondering if web
workers in future React versions will change that story.

~~~
pluma
In case you missed it, the author confirmed the tests were accidentally using
the development version of React, which is significantly slower due to the
additional warnings and sanity checks. The actual results seem to be much less
surprising.

------
underwater
You should compare a plain JavaScript object (use shallow or deep compare if
you must) version against Vue.

I'm sure Immutable is pretty well optimized, but you still have overhead from
all those function calls and iterating through the array of keys manually.

~~~
TheCoelacanth
Exactly this. Immutable is for collections, e.g. maps, sets, lists. The
objects in the example are just objects, they are not maps. Using Immutable is
just a pointless complication.

