ReactJS is quicker than you'd expect for a gigantic JavaScript-based DOM diffing engine, but somehow this got distorted into the misconception that it's faster than native. It's not.
Like with most new technologies, we're currently in the phase where we're overusing it. In the long run, this will hopefully even out into a state where React-style DOM abstraction instead becomes just one more tool to be used when appropriate.
Well, since react forces a diffing algorithm for every state changes. It is difficult to create realtime components that update every few millis to get a 60 fps framerate. I think that is what is happening here. Dragging in the color pickers causes a tree-diff algorithm to kick in on every on-mouse-move event.
As a complete outsider, do you have a link or two to support that so I could learn more?
It would seem to me, again completely without knowledge, that a virtual DOM seems suboptimal. Web browsers should be able to optimize for that use case a lot better.
Pete Hunt's talk is good. https://youtu.be/x7cQ3mrcKaY?t=1112 I'd recommend watching the entire video if you have time, but that's the gist of it. More detail:
It is challenging to make a large app with lots of state be performant when you manually mutate the DOM, and there's no way for the browser to fix that because of the way things work.
For example, if you move an element, and then request the position of another element immediately after, the browser will be forced to recalculate layout before giving you an answer. With lots of state and lots of updates, it's very challenging to keep this in the right order.
As virtual DOM is an abstraction over the DOM, you can make a vanilla app that is much faster, but as your app grows, that quickly reverses.
The more correct selling point is that you should be able to get "good enough" performance (usually meaning consistent 60fps) with properly optimized React code.
Where did you notice a lot of lag (what device and where on the site)? I thought the performance was very good within a single widget, but there's obviously some debubble going on when updating the linked components
Try dragging your mouse (while holding the mouse button) in the "Saturation" component (its the square with rainbow colors). Every mousemove event causing the react action-render-treediffalgo-dom-mutations loop to kick in. Which is too slow to keep up with the mousemove events.
Gotcha, I got it to sputter a bit when wildly flying back and forth, but it seemed smooth under "normal" circumstances. I'm on an i7 though so, decently different hardware test ;-)
I'm running this on an 8-core Intel chip with 16GB of RAM and 4GB of Video memory and it was lagging, like _stepping_ really during all dragging. I confirmed it on 1-year-old Macbook too.
Did that lead to downvoting? I'm just curious how questions about expanding on test conditions aren't considered valuable, especially when they could clarify when to use / not to use this component...
Did what lead to downvoting? I'm not sure what you're asking. I think your parent comment might be downvoted because the wink at the end comes off as condescending.
Like with most new technologies, we're currently in the phase where we're overusing it. In the long run, this will hopefully even out into a state where React-style DOM abstraction instead becomes just one more tool to be used when appropriate.