I repeat: there was never any basis in fact for the idea that VDOM was "fast", still isn't. It's trading space for *convenience*, not speed.https://twitter.com/slightlylate/status/901577573221548032 …
-
-
Replying to @slightlylate
No basis in fact... https://github.com/marko-js/marko-vdom/blob/master/docs/benchmark-results.md … Perf is part of it, just not the whole thing. Blanket statements undermine your message here
2 replies 0 retweets 1 like -
Replying to @tbranyen @slightlylate
Then again I'm sure I'm guilty of the same thing. Just kinda bothering me that you're making VDOM out to being slower...
1 reply 0 retweets 0 likes -
Replying to @tbranyen
Ok, so I looked at this; the generated DOM code might as well be `p.innerHTML = ""; ...`. VDOM version doesn't create any DOM. ¯\_(ツ)_/¯
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tbranyen
Like, I built the marko-vdom lib from source and set a breakpoint in the `actualize` method. Never called. Lawlz.
3 replies 0 retweets 0 likes -
Replying to @slightlylate @tbranyen
What we've learned here today is that creating JS objects w/o DOM backing is cheaper than creating DOM. Also: tends to be less useful.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tbranyen
Patching the benchmark now...this oughta be fun...
1 reply 0 retweets 0 likes
Ok, patched. Either DOM or innerHTML is faster than Marko in all of these tests.
-
-
Replying to @slightlylate @tbranyen
React still scoring higher, but I suspect this is also apples/oranges; probably caching.
1 reply 0 retweets 0 likes -
Replying to @slightlylate @tbranyen0 replies 0 retweets 0 likes
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.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.