I did not include the link in this post. The admin sent me an email advising me to re-submit. Thanks for pointing that out.

^ This

The irony is you are the extremist for thinking HN is full of extremists! :)

Also, library size !== mediocrity at all. No one builds an unreasonably large framework on purpose either.

> So far, the Infinite monkey theorem is just giving us an infinite number of javascript frameworks, and no Shakespeare

Not even funny IMO. This is the kind of toxic comment that don't motivate progress in this community.

Take it easy, it's just a joke that I post to every JS framework thread on HN:)

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.

If all goes according to plan, it will look even more like Elm in the next major release (2.0).

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.

Yes. Not IE8, though.

Hyperapp will be a lot more Elm-like in a future release, see this too: https://github.com/hyperapp/hyperapp/issues/672

HyperTerminal