7 ms·
Quicker than what? And a framework choice doesn't guarantee a certain level of responsiveness, it also comes down to the implementation.
by watty 11y ago
Quicker than what? And a framework choice doesn't guarantee a certain level of responsiveness, it also comes down to the implementation.
- jarek-foksa 11y agoOne of the primary selling points of React is better performance of the virtual DOM, which apparently has no prove in benchmarks [1]. [1] https://aerotwist.com/blog/react-plus-performance-equals-what/ https://aerotwist.com/blog/react-plus-performance-equals-wha...
- clessg 11y agoThat article has been discredited pretty thoroughly. Anyway, it's not a panacea. It can't do much if you're forcing a reflow every few milliseconds.
- JDDunn9 11y agoIf by discredited you mean lots of React fanboys whined about it then yes. If you mean anyone showed actual evidence to the contrary, then no.
- clessg 11y agoCall people fanboys all you want, but after the code was released, numerous glaring issues were found, and still haven't been addressed.
- xorcist 11y agoAs 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.
- clessg 11y agoPete Hunt's talk is good. https://youtu.be/x7cQ3mrcKaY?t=1112 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: http://stackoverflow.com/questions/21109361/why-is-reacts-concept-of-virtual-dom-said-to-be-more-performant-than-dirty-mode http://stackoverflow.com/questions/21109361/why-is-reacts-co... 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.
- jarek-foksa 11y agoShadow DOM will allow browsers to optimise their rendering code to re-render encapsulated DOM subtrees independently of each other. Virtual DOM makes sense when (A) you have a huge tree and (B) you show only a small portion of that tree to the user at any given time. For example a long scrollable list or a multi-line text editor would be better implemented with virtual DOM, but using it everywhere is an overkill.
- baddox 11y agoThe more correct selling point is that you should be able to get "good enough" performance (usually meaning consistent 60fps) with properly optimized React code.
- TeeWEE 11y agoWell, 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.