Tentative conclusion after being burned in performance too many times: Diffing (like in React, but by no means is this unique to React) is a sign that there's something wrong with your framework design.
-
-
There is a language runtime barrier which likely spends some locking overhead. That's one down side. The other downside is that the DOM's API isn't very "functional". IIRC, supplying `.src` on an iframe is not idempotent and could reload the iframe just as an example.
-
I'm also curious if, in addition to the locking overhead, there's also some additional costs of allocating many short-lived DOM objects over and over (DOM wasn't meant to be used that way). I understand browsers all have to implement their own DOM/GC interop(cycle breakers?)
- 2 more replies
New conversation -
-
-
Diffing doesn’t just solve the problem of interacting with the DOM. It also takes care of component tree lifetimes and allowing for transient data structures to act as if they’re long loved (apparently).
-
This is something that webcomponents don’t offer implicitly, not in such a way that the UI remains a pure function of state. Diffing allows composition of presentation to act as if it’s a relatively efficient composition of mutations. Very interested in figuring out alternatives.
End of conversation
New conversation -
-
-
Even if creating DOM elements was cheaper than JS objects, we'd still have to diff - performance is only one reason, the other (more important) reason is to preserve existing elements and cursor position, focus, selection state, etc.
-
Not that I disagree, actually. I'd love to see more compile-time UI frameworks like Svelte that solve UI updates without diffing!
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.