3 ms·
> because diffing the Virtual DOM adds heavily to computation costs if you aren't being extra careful or as the application grows to real-world size, especiall
by password11 4y ago
> because diffing the Virtual DOM adds heavily to computation costs if you aren't being extra careful or as the application grows to real-world size, especially in mobile.
Is there some recent study showing evidence or analysis of this? You're saying the main root cause of poor performance is the diff burning up CPUs?
I always assumed applications run slowly because people are overusing global (redux) state and every state change is subscribed to by like 10 different components. And people making 5 network calls before their component meaningfully renders.
- HereBeBeasties 4y agoAs ever, it depends on your use case. If you're rendering 20 TODO items then who cares? If you're rendering thousands of items on an SVG data visualisation, sure it matters. You can tell it matters because otherwise React wouldn't have implemented escape valves to improve performance, like shouldComponentUpdate. You can get around this by using persistent data structures with lenses, which is how Elm works. Then it's just reference equality checks as you go down the tree, which is inherently faster.
- password11 4y ago> If you're rendering thousands of items on an SVG data visualisation, sure [virtual dom] matters. I am not educated on the no-virtual-DOM-hype. What actually costs more here: (1) the diff and vdom algorithm or (2) the actual DOM calls? I always thought it was (2)... is this right?