Hacker News Reader

Comment by ulizzle | Hacker News Reader

Yeah, it does have significant performance improvements, 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.

No VDom is always faster than having a VDom.

But I do agree with your point 100% that it should tell you right away about it on the README what that means, and the significance behind the claim.

View on HN

No, it's not always faster.

IIRC in a recent stream the author of Solid showed that it's hard to beat a proper VDOM implementation when you have 1000s of elements.

And most naive non-VDOM implementations will probably lose to a good VDOM implementation.

That’s true, but you can say the same thing about reactivity: not having it is always faster than having it. These are not zero-cost abstractions; we use them because the alternative tends to be less performant at scale, but technically you can always beat them by going in and manually updating the DOM yourself.

> 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.

As 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.

> 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?

Reply on news.ycombinator.com