Come on boffins!https://youtu.be/5A8CDJaQCqo
-
-
In theory, the `O(
#element)` cost can be significantly reduced using `shouldComponentUpdate` to prune the tree. Not used enough in the wild? -
"VDOM! Now I don't need to manage state updated in my component!*" * please shouldComponentUpdate() responsibly; mobile perf not advertised
- 7 more replies
New conversation -
-
-
Best case, vdom helps avoid scheduling issues, but what I see in traces is *huge* per-element overhead
-
The way FWs attempt to efficiently update DOM are not exactly without overhead either, though. Wouldn't a native DOM-morph API help?
- 10 more replies
New conversation -
-
-
+1. This was exactly the reason for once - DOM diffing without any intermediate data structureshttps://github.com/utilise/once
-
"DOM is slow" was hugely misleading. DOM is not slow to walk, or read. Updates may be slow. Vdom is just buzzword for memoization.
- 13 more replies
New conversation -
-
-
Construct 3 has no VDOM and is fine. No DOM perf issues. Layout perf is *much* more significant:https://www.scirra.com/blog/ashley/35/layout-is-the-next-frontier-of-web-app-performance …
-
IMO this whole VDOM debate is big distraction, once you solve DOM perf you hit the layout performance wall. We need to improve that instead
- 12 more replies
New conversation -
-
-
VDOM memory overhead has definitely been a concern for any teams I've seen using it with large trees.
-
Yep, try and use DOMParser at 60fps with any homepage markup.... sure it parsers in subsecond times, but at the cost of huge GC concerns
- 2 more replies
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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.