yew
yew copied to clipboard
yewstack
Performance details
This is a very impressive framework. I would offer it would be useful to know about the performance of it's use. If there are best strategies or bad practices to be avoided. Also it would be useful as evidence for people considering it in production projects vs other frameworks.
Because of the indirection from compiling Rust to JavaScript/WASM, it'll probably be likely to be slower than your typical React (and Redux), Preact, or Vue web app.
True :) but how much slower. There may be many application that are still possible with this framework. A good stress test might be a data grid. Or maybe something else.
@richardanaya Thank you for the request. I think I can do some checks on holidays 👍 I'll report here.
The difference might be that the modern frameworks have do a lot of optimization on performance.
I've finished the first benchmark with Firefox 57.0.1 (64-bit) + pure wasm target wasm32-unknown-unknown. I can't believe that! Maybe something wrong?!
Source: https://github.com/DenisKolodin/todomvc-perf-comparison
Some frameworks have updated so much, but todomvc-perf-comparison's latest updating was in three years ago.
However, it is still amazing that yew does well!
That's crazy! Definitely worth trying to implement an entry into this benchmark, though, as it's quite highly regarded.
@rivertam https://github.com/krausest/js-framework-benchmark is a good option for benchmarking this framework 👍 I will implement it a little later.
For large applications with deep hierarchy of components, yew can show the result worse than redux-like because yew has no alternative to shouldComponentUpdate(): it makes full update every frame.
@loyd That's a good point. I don't think such a thing is possible before components (#1) are added, however. I could be wrong on that, of course.
I don't think this is necessarily true.
I'm looking a bit more closely into Elm, and it doesn't have this idea of componentShouldUpdate. Elm is favoring views (analogous to stateless React components) instead of components (like React component classes, with lifecycle methods etc.)
So it doesn't require you to write some logic to help the vdom algorithm do its thing, yet the benchmarks I've seen so far (like the one above) are indicating that Elm is actually quite a bit faster.
This is probably worth a read : http://elm-lang.org/blog/blazing-fast-html-round-two We should probably discuss this a bit more before going too deep in one direction.
Quick follow up, the first version of the article goes a little deeper into technical details, the part about laziness is pretty key I think.
However, with Yew's model being mutable I'm not sure we can achieve the same thing. Doing something equivalent would require immutable data structures. The author of rpds conveniently posted this on Reddit just yesterday.
Laziness via immutable is one of the ways to implement idea of componentShouldUpdate (no matter automatically or manually). I mean, React+Redux and Elm have equivalent optimizations.
Yes, the use of immutable structures is the simplest to do such optimizations. Another way is vuex-like approach, which is not very useful in Rust. Immutable storages have other advantages also: cheap time travel, optimization aggregate functions via selectors and so on.
In theory, it may be possible to use merle trees or iterative hashing to determine differences after every update(), but I think immutable data is a better choice.
@DenisKolodin what do you think about immutable data (fn update(ctx: &Context, model: &Model, msg: Msg) -> Model)?
Another thing about performance: I think yew should separate the stage of building patch and the stage of applying patch (like in virtual-dom library). It allows to apply patches in the main ui thread, while the application works in web workers.
So in a normal setting with the wasm32-unknown-unknown compilation what would be the expected performance of yew vs a react or vue app.
I've seen some comments here saying it would be slower, but judging at the benchmark (even when its old!) shows that there is certain prominence here.
What are sort of the points in which the speed can be improved?
@DenisKolodin Any progress on a better benchmark?
I checked the TodoMVC application (in an attempt to see if I could bump the React version for better reference), and unfortunately found that the Yew benchmark has quite a different UI than the other benchmarks, rendering it invalid.
Hi there! I came across this benchmark and was surprised to see Yew performing better than a vanilla JS implementation, so I looked into it. Using the benchmark's step button, it would appear the Yew bench is skipping rendering 49 of the 50 todo list items, and never updates them to be checked. This is the reason the numbers are so low.
Here's a video showing the effect, compared to the Vue implementation:
I've pointed out with my mouse where the important difference becomes apparent.
Any update on this? Someone said that yew would be slow (presumably compared to something like react) but I'm not sure how credible that claim is.. But people often said that the js ffi bridge to the DOM API is slow.. But the question is, how slow does it make yew apps compared to js frameworks?
I contributed yew dcd3834dd915647f4eae1ec78b6d803b70fad1da and stdweb 0.48.0 benchmarks to https://github.com/krausest/js-framework-benchmark .
Results are here:
https://rawgit.com/krausest/js-framework-benchmark/e713af4db483ffc627798caa6f5ea0ac4ca1e5fd/webdriver-ts-results/table.html
Thanks @saturday06, it seems to be quite slow and memory-intensive (also my experience in my current app). Do you have any idea how this can be improved?
E.g. I often find myself having to clone state structs that are passed down to children as properties, is there a way to only pass them by reference? And currently it's not possible to only update child state (or query children) without re-rendering the parent's DOM: https://github.com/DenisKolodin/yew/issues/350 (This causes high CPU usage in my app because the whole app's DOM is being re-rendered at 30 fps (the rate at which WS msgs are received by the main app component, even though each msg should only change a small child's state, ideally).
@saturday06 Excellent work! It's the first good benchmark and it's time to start improving the performance. I'll explore this issue and how to speed it up :rocket:
It'd be interesting to redo the Yew benchmarks with the fast Wasm to JS calls: https://hacks.mozilla.org/2018/10/calls-between-javascript-and-webassembly-are-finally-fast-%f0%9f%8e%89/
@voidpumpkin, assigning this to you since you're working on it and it's mentioned in the documentation
