4 ms·
That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen The VDOM definitely carried overhead in my case, b
by brundolf 5y ago
That's bizarre; I've spent a lot of time spot-optimizing React apps and never had something like that happen
The VDOM definitely carried overhead in my case, but it was easy to profile and optimize (with the React tools). In many cases, reflowing the sheer size of the DOM we were generating was a bigger bottleneck than the time it took React to render it in the first place
I'm really curious what was going on in your app
- danielvaughn 5y agoI've seen it a lot, personally. I've even seen instances where the input would delay by over a second. Really wild stuff. Can a better design help to mitigate those issues? Sure. But I don't like having to wonder whether it was my own design, or if it's something internal to the library.
- brundolf 5y agoI think we're talking about two different things- I've definitely seen that much delay before, but it always came down to inefficient rendering logic and/or components that re-rendered excessively often, both of which are easy to detect in profiling and usually not too hard to solve This is the part I thought I was bizarre: > The React profiler wasn’t able to show any latency in my render functions and using the browser profiler I saw that all time was spent somewhere inside React’s internal
- bastawhiz 5y agoThere's nothing inherently slow about React internals. It does exactly the work you tell it to do. If you tell it to do too much unnecessary work, it'll happily go do that. Svelte avoids this by magically not doing the unnecessary work. That doesn't mean it's faster, it just means your design needs to make different kinds of considerations.