hyperhtml Update 2/3/2018: Please note that hyperhtml was incorrectly categorized as non-keyed in the results of round 7. The version 2.4 of hyperhtml performs much faster than 1.12.5 as can be seen from the snapshot of the table for the next round. Results of 1.12.5 have been removed from the table.

Further the were new major releases for react and angular. All in all there are currently 76 framework variants in this round. A big thanks to all contributors to this round!

What’s the benchmark about?

The benchmark measures the duration for simple operations on a (unrealistic) large table with either 1,000 or 10,000 rows depending on the operation. The measurement is extracted from chrome’s timeline via browser automation and includes the time for rendering.

Why are results grouped in keyed and non-keyed?

Keyed implementations create an association between the domain data and a dom element by assigning a ‘key’. If data changes the dom element with that key will be updated. This feature might be necessary when integrating with 3rd-party libraries, transitions or when the DOM keeps some state. Non-keyed implementations are free to reuse the existing dom nodes in whatever way they like and thus might be faster, but may cause issues if there’s a dependency on the particular dom nodes.

If you want my opinion I’d only ever choose a framework that supports keyed updates, non-keyed only frameworks seem like a premature optimisation to me, but your requirements might vary.

A deeper look at the keyed results

React 16 is really an improvement. It pushes react in front of preact and vue.js. Using the “compare with” feature for react yields the following picture:
Green cells are statistically significant faster (the color indicates the p-value, light green is 10% with darker green for lower p-values) and red ones are slower. For white cells no statistic conclusion can be drawn.
Angular and react are very close, especially with the no-zone variant. Preact has lost its performance advantage on react 16 and react-lite is far behind. The partial update benchmark uses 10,000 rows in this round, since it was below the 16 msec frame window with 1,000 rows for most frameworks and thus didn’t show much differences between the frameworks in the last round. Vue.js doesn’t seem to like the larger table for that particular benchmark, but is very competitive for the others.

Further links

If you want to run the benchmarks on your machine just follow the README.

I am happy to see the growth in numbers of measured libraries. As a library developer myself I have used your benchmark to spot bottlenecks and remove them from the code.
I think you should dedicate a section in your post for memory consumption and startup time – as this is more critical to low-performance machines like tablets, “netbooks” and mobile devices, perhaps even more critical than rendering thousands of items. Those machines today have more internet traffic than desktops.

I have weird issue if I select following 4 in filter, vue gets in front with different value than when looking at the big table
bobril-v8.0.1-keyed vue-v2.5.3-keyed angular-v5.0.0-keyed react-v16.1.0-keyed angular-v1.6.3-keyed

@Jack: the slowdown geometric mean is always calculated against the currently selected frameworks. Unless you have the fastest frameworks in all tests (vanilla, surplus, pico-dom) you’ll get different values. The relative order should be the same in any case.
So I think that’s ok.