3 ms·

It's not very performant compared to other v-doms https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/

It's not very performant compared to other v-doms https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...

gandreani 8y ago
Wow kudos to the author! Very nice resource
ricardobeat 8y ago
hyperhtml - which this is based on, similar API - can be found at the left end of the table.
starbuzz 8y ago
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.
- bufferoverflow 8y ago
  It's not old, it was last updated two days ago: https://github.com/krausest/js-framework-benchmark/commits/master/webdriver-ts-results/table.html https://github.com/krausest/js-framework-benchmark/commits/m...
  - starbuzz 8y ago
    I meant the benchmark is using an older version of Hyperapp. https://github.com/krausest/js-framework-benchmark/tree/master/frameworks/hyperapp-v1.2.0-keyed https://github.com/krausest/js-framework-benchmark/tree/mast... The js-framework-benchmarks is very much maintained and actively developed. It's our go-to benchmark when fine-tuning for a new release. In addition to that, the latest code on master (still unpublished) includes some notable improvements: https://github.com/hyperapp/hyperapp/pull/663 https://github.com/hyperapp/hyperapp/pull/663
starbuzz 8y ago
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 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.

gandreani 8y ago

Wow kudos to the author! Very nice resource

ricardobeat 8y ago

hyperhtml - which this is based on, similar API - can be found at the left end of the table.

starbuzz 8y ago

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.

bufferoverflow 8y ago
It's not old, it was last updated two days ago: https://github.com/krausest/js-framework-benchmark/commits/master/webdriver-ts-results/table.html https://github.com/krausest/js-framework-benchmark/commits/m...
- starbuzz 8y ago
  I meant the benchmark is using an older version of Hyperapp. https://github.com/krausest/js-framework-benchmark/tree/master/frameworks/hyperapp-v1.2.0-keyed https://github.com/krausest/js-framework-benchmark/tree/mast... The js-framework-benchmarks is very much maintained and actively developed. It's our go-to benchmark when fine-tuning for a new release. In addition to that, the latest code on master (still unpublished) includes some notable improvements: https://github.com/hyperapp/hyperapp/pull/663 https://github.com/hyperapp/hyperapp/pull/663

starbuzz 8y ago

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 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.