4 ms·
They sacrifice all the crazy performance optimisations that React has.
by ylyn 6y ago
They sacrifice all the crazy performance optimisations that React has.
- vijaybritto 6y agoTBH preact is faster than React. I don't know of a scenario where react was faster.
- runawaybottle 6y agoHow do you measure? I’d love to see large renders and complex top level state updates that hit hundreds of components.
- williamstein 6y agoThis is relevant, though it is 2 years old: https://medium.com/@ajmeyghani/javascript-frameworks-performance-comparison-c566d19ab65b https://medium.com/@ajmeyghani/javascript-frameworks-perform...
- vijaybritto 6y agoI worked on a project where we were using React 14 before 2 years. It was only a desktop B2B site and later on when mobile support was inevitable we tried to use preact for mobile site since it was lightweight. We actually found that our desktop site which renders large tables with hundreds of rows and multiple chart components performed better in Preact without any optimizations. I'd say maybe a 20 - 30% improvement since we were seeing a gain FPS of around 10 frames. I think it would have been a bit more faster if we had used MobX instead of redux but that was too late.
- jamil7 6y agoHaven’t worked with React for a little while and only ever used MobX on one project, I was mostly using Redux. What performance improvements does MobX offer?
- vijaybritto 6y agoRedux always returns a brand new state. This will cause all consumers to rerender and react will update the dom only if there is a change. But with Mobx its more granular and the updates are atomic. This isn't a problem in apps where there is a single team working on it. But when you work in enterprise apps where different parts are worked on by different teams state updates to redux can be costly. This is not a limitation of Redux but a human problem that occurs inevitably. I've seen this in 3 different large scale projects. It starts well but after a year or so when people move out/in this bites us. This can be enforced with strict rules, eslint plugins and infra but they are expensive as hell. EDIT: 'This will cause all consumers (with incorrect mapStateToProps configuration) to rerender'
- jamil7 6y agoUnderstood, this is the reason I suspected and have spent considerable time in the past optimising state updates to forms in React and Redux projects so can imagine how this would become an issue in much larger teams than the ones I was working in.
- tga 6y agoWhen using Redux, components are supposed to select small parts of the state tree, and then they only rerender when those change. It is absolutely not the case that all components render on each unrelated update of the global state, that would be crazy. https://react-redux.js.org/next/api/hooks#useselector https://react-redux.js.org/next/api/hooks#useselector It is true that all of the selector functions need to run on each change, but those are supposed to be really small pure functions and their performance should be negligible, compared with everything else that normally happens in an app. Edit: It is absolutely possible to affect performance with Redux, especially on a large app — for example if hundreds of selectors need to run for every keystroke in a textbox.
- jamil7 6y agoYeah this is correct, I think what the OP was getting at was the fact that Redux requires a little more discipline as it's less opinionated than MobX.