What does HackerNews think of js-framework-benchmark?
A comparison of the perfomance of a few popular javascript frameworks
There actually is for web frameworks https://github.com/krausest/js-framework-benchmark
I don't even know if they have the OnPush version of Angular implementation (which would be fair), but if they don't - I hope someone will build it soon.
----
And while we are here, please create a Qwik implementation!
Unfortunately there aren't any good resources on this topics. Everyone is just focusing on a diffing and unable to see a bigger picture. In the end, all feature-complete libraries implement diffing algorithms for dynamic children lists and attribute diffing for "spread attributes", so with this features we are kinda already implementing almost everything to work with DOM and create a vdom API, everything else are just slight optimizations to reduce diffing overhead. But working with DOM is only a part of a problem, it is also important how everything else is implemented, all this different features are going to be intertwined and we can end up with combinatorial explosion in complexity if we aren't careful enough. Svelte is a good example of a library that tried to optimize work with DOM nodes at the cost of everything else. As an experiment, I would recommend to take any library from this[1] benchmark that makes a lot of claims about its performance, and start making small modifications to the benchmark implementation by wrapping DOM nodes into separate components, add conditional rendering, add more dynamic bindings, etc and look how different features will affect its performance. Also, I'd recommend to run tests in a browser with ublock and grammarly extensions.
And again, it is possible to implement a library with a declarative API that avoids vDOM diffing and it will be faster that any "vdom" library in every possible use cases, but it shouldn't be done at the cost of everything else. But unfortunately, some authors of popular libraries are spreading a lot of misinformation about "vdom overhead" and even unable to compete with the fastest ones.
https://github.com/krausest/js-framework-benchmark
Great work so far, I’m excited to give imba a spin.
https://github.com/krausest/js-framework-benchmark https://localvoid.github.io/uibench/
Or even just something following mithril’s own benchmark suite: https://github.com/MithrilJS/mithril.js/blob/next/performanc...
My best guess to understand it is:
- On the horizontal axis, we have consecutive Chrome releases.
- On the vertical axis, we have total time of benchmark execution, relatively to Chrome 75
The source of the data is the "js-framework-benchmark"[0] run in a controlled environment in Chrome[1]
[0]: https://github.com/krausest/js-framework-benchmark
[1]: https://krausest.github.io/js-framework-benchmark/2020/table...
The answers to those questions should be on your home page.
Also it would be great if you included it here: https://github.com/krausest/js-framework-benchmark
It's an excellent project, pretty decently fast (checkout the js-framework-benchmark[1] code, or more specifically the results of round 8[2]) -- but is currently suffering from a lack of recognition. It's the kind of project that absolutely doesn't care about that kind of metric (as in, the team seems to be more focused on slow, steady improvement of the library rather than chasing stars on github), but I figured I should say something.
Shameless plug: I recently really wanted to contribute something (and kick the tires more) so I wrote an article that goes through replicating a simple mail design I saw[3] -- it might be a decent overview of what mithril is like to write (though I'm certainly not a mithril expert).
This brings me back to the point at hand -- as others have noted, in my opinion one of the best things about hyperscript is the straight-forwardness with which you construct the render function. I'm not convinced it's necessary to segregate stateless/stateful components -- and mithril is simpler in that it doesn't introduce this dichotomy -- in the end there's the render function, and that's it. If you want to use state, go ahead -- if you don't, then don't. It's the simplicity I've wanted from component frameworks (and mostly get with Vue) without any of the posturing/looming complexity.
Also there's the fact that you could write a completely vanilla es5 application with hyperscript (arguments whether you should or not aside) -- JSX is/was revolutionary, but is basically required in practice, which often makes people jump into bed with webpack without thinking, and makes frontend development harder than it has to be.
[EDIT] - Another point for mithril is that it's self contained -- routing and ajax calls some with the framework. When people these days talk about "react" or "vue" what they're really talking about is react/vue + react-router/vue-router + flux/vuex and some other odds and ends. Mithril is by far the simplest and most feature-complete of these frameworks despite being smaller (both conceptually and on-the-wire).
One of my only current gripes with Mithril is the lack of controllable subtree rendering (it isn't as much of a problem in practice, but more me wanting to optimize early).
[1]: https://github.com/krausest/js-framework-benchmark
[2]: https://www.stefankrause.net/wp/?p=504
[3]: https://vadosware.io/post/mithril-systemjs-and-rollup-gettin...