Don't look at "overall time" to compare performance, I've added it just because some of the vdom library devs asked it, so they can easily track regressions/imp

Don't look at "overall time" to compare performance, I've added it just because some of the vdom library devs asked it, so they can easily track regressions/improvements in their libraries. Numbers in this benchmark aren't so useful if you aren't a vdom developer, some libraries were broken(the last time I've checked), some using caching to get ridiculous render times, etc. >Is that argument correct? Is reading the DOM actually not so problematic, as long as the modification you make to it are minimal (which seems to be the strategy here)? If you want to squeeze out as much "performance" as it is possible, most of the time you'd want to avoid reading DOM (even simple reads, not something that triggers render/layout) And when it comes to minimal number of modifications, most popular libraries even fail on cases like "moveFromEndToStart or moveFromStartToEnd" (depends on the direction they traverse DOM), they will make N-1 moves. But in the end all this numbers doesn't matter too much, React is fast enough for most use cases, its community and ecosystem is way more important than numbers in this benchmark.