I'm shit at writing, but I've got this idea for a possibly faster vdom implementation so here goes - https://github.com/yoshuawuyts/nanodiff/issues/1 …
-
-
Replying to @yoshuawuyts
that said, I've got barely any clue on how existing vdom implementations are done; there are so many!
1 reply 0 retweets 1 like -
Replying to @yoshuawuyts
But from benches morphdom isn't the fastest, and doesn't appear to work like I describe here, so perhaps this might be neat
2 replies 0 retweets 0 likes -
Replying to @yoshuawuyts
let me ask you this — is dom diffing the bottleneck?
2 replies 0 retweets 0 likes -
yeah, it could be - not usually but it's the extreme cases that would act violently; capping them without API change would be neat
2 replies 0 retweets 0 likes -
Replying to @yoshuawuyts
in the super hot path i always go with vanilla JS and target the exact nodes i intend to update, but diffing/patching... 1/2
1 reply 1 retweet 1 like -
Replying to @heapwolf @yoshuawuyts
is in comparison, inherently inefficient (any way you look at it, its an abstraction), so why dom-diff when perf maters? 2/2
1 reply 0 retweets 1 like -
I respectfully disagree here - I think the logic to handle the custom updates may sometimes be heavier than a single diff per frame
2 replies 0 retweets 0 likes
but perf is def not the focus point of vdom updates - mental overhead is; all perf talk is to find ways to manage the cost associated
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.