Join GitHub today
Add additional benchmark for optimized implementations #7
What we truly need is to more clearly explain what the benchmark is measuring. And it is probably not even that relevant to benchmark KVO frameworks. See documentation from Glimmer:
We are essentially trying to measure "re-evaluating the component tree to figure out how the DOM needs to be mutated. Essentially, that means doing a full render pass on a component and all of its children every time a property changes."
My assertion is that Imba introduces a third approach, which looks a lot like Virtual DOM diffing, but is doing it in a very different (much faster) way. It allows for the same performance as "1. fine-grained property observation" without any of the complexity or memory usage. You can manage your state however you want, and still get the performance.
Yeah I tend to agree with this statement. KVO was designed to sidestep this problem entirely and predates the VDOM by a good 5 years. It classically did this in a way that made initial render slower. This (along with the general state of jQuery frontends) was the window that allowed VDOM libraries make performance claims and gain ground with arguably less performant and overly complicated solutions.
I do think this is a 3rd approach. There are only a handful of libraries that I know are doing this. It has the ability to not force rerunning the whole code base similar to fine grained KVO, and still has the top down re-render found in VDOM. As it turns out simply equality checking against memoized value at DOM assignment level is generally more performant over even 10k records than following the subscriptions to update the few places that updated. KVO when there aren't many changes is generally faster at these partial updates, but as soon as you consider initial render and cleanup, and other scenarios the benefits start decreasing. It is an interested race though since all the approaches can borrow a bit from each other. In the JS Framework Benchmark the 3 top libraries are an example of each approach DomC(DOM Reconciliation), Surplus(Fine Grained KVO), ivi(VDOM).
What that does mean though is this benchmark is basically non-applicable to KVO and is hugely biased against VDOM libraries which intend to avoid this scenario. Which means it isn't a real comparison testing each library on it's merits, but I'm getting that isn't the point here. It's more to just show performance in this one scenario.
React implementation is doing extensive binding everywhere, those should be moved to constructor outside render and loops...