Performance details

[richardanaya]

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.

[dashed]

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.

[richardanaya]

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.

[therustmonk]

@richardanaya Thank you for the request. I think I can do some checks on holidays 👍 I'll report here.

[NamPNQ]

I don't think wasm slower than js, if it does not call any js

[tigercosmos]

The difference might be that the modern frameworks have do a lot of optimization on performance.

[therustmonk]

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

[tigercosmos]

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!

[rivertam]

That's crazy! Definitely worth trying to implement an entry into this benchmark, though, as it's quite highly regarded.

[dashed]

That does seem surprising. 👍

[therustmonk]

@rivertam https://github.com/krausest/js-framework-benchmark is a good option for benchmarking this framework 👍 I will implement it a little later.

[loyd]

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.

[rivertam]

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

[kamek-pf]

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.