Hyperapp is not optimized to be the fastest framework at the expense of worse developer experience. Having said that, we're definitely working on improving our runtime performance (see https://github.com/hyperapp/hyperapp/issues/499). So much to do!
I want to point out that while these benchmarks are very useful to detect underlying, potentially serious runtime and memory performance issues in your algorithm/framework, the implicit idea that even the slowest framework according to this list (e.g. choo) is a poor choice or inadequate for frontend development is ridiculous (the js-framework-bench creates > 80,000 nodes).
Please don't do that to your users, regardless of the framework you are using. Even the most complex user interface will have < 10,000 nodes. Tables/grids may get you there faster, however.
Still, in the case of Hyperapp we're talking about 100 to 200 milliseconds slower in the worst test (i.e., partial update) for a worst-case scenario.
Hyperapp and Web Components is a great combo, especially because they can help with the problem of maintaining local component state, not a feature of Hyperapp.
This is an old benchmark, we're in the same ballpark as React now. Hyperapp is also not just a virtual DOM, but also a state management "all-in-one" kind of thing.
Some of those results refer to HyperTerminal, the Electron-based terminal app. Other results refer to Hyperapp-like libraries (not Hyperapp). The most recent submission related to Hyperapp was 8 months ago and Hyperapp has come a long way since then.
Here is another angle to this: go into React type of submissions and ask them to stop spamming HN with that?
Hyperapp is based on virtual DOM and yes, I guess you could say it's inspired by Hyperscript in the same way as all virtual DOM based libraries or frameworks.