I'm pretty sure this benchmark doesn't show anything meaningful w/o `actualize()` call
-
-
Replying to @slightlylate @tbranyen
It shows that when creating and walking a tree to do diffing/patching, VDOM is significantly faster.
1 reply 0 retweets 0 likes -
Obviously in the case of *inserting* a completely new tree, innerHTML is going to be faster than VDOM.
1 reply 0 retweets 0 likes -
If you're creating VDOM nodes and then actualizing all of them, its redundant and defeats the purpose of being virtual.
2 replies 0 retweets 0 likes -
Replying to @mlrawlings @tbranyen
What's the point of a benchmark that compares the cost of an abstraction (that must be used w/ substrate) to the substrate?
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tbranyen
Because the substrate doesn't provide diffing/patching. Setting innerHTML on a node blows away the entire subtree.
1 reply 0 retweets 0 likes -
And as I point out later in the thread, we don't need to actualize (call the substrate) in the majority of cases.
2 replies 0 retweets 0 likes -
Replying to @mlrawlings @tbranyen
Yeah, I think you're missing my point: there's no legitimate comparison here.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tbranyen
For us there was: it's a direct comparison against what we were doing. But, using this to make a blanket statement VDOM > DOM is invalid.
1 reply 0 retweets 0 likes -
Replying to @mlrawlings @tbranyen
This benchmark proves no point. It might if you didn't include the DOM variants (per-framework diff cost) or had a realistic DOM update.
1 reply 0 retweets 0 likes
Are there cases where you build up such a structure for diffing and *don't* do the side-effect work? Is that common?
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.