In benchmarks, it looks really good. This benchmark isn't perfect, though - it's a contrived example and the competitors are using outdated versions. There's some good discussion in this issue - including a benchmark where yew is among the slowest measured. It turns out in that first graph Yew was skipping outright some of the calculations that were clogging up the other numbers - both a point for Yew's optimizations and against the integrity of the benchmark.
The real-world story is complicated, in short. It's not a guaranteed speedup, but in a lot of cases will likely be faster than a line-for-line translation from React. The JS <-> WASM bridge is a work in progress - it's already made leaps and bounds since I started playing with Yew, but any time you cross the FFI boundary there is going to be overhead to contend with and the performance of any given app is somewhat unpredictable - there are a lot of variables.
For now, the best approach for maximum performance would be to stick to traditional frontend tools and isolate computationally heavy operations. You can abstract these hot code paths out to their own WASM modules, and organize so that there isn't a ton of data being passed back and forth. You are also able to interact with WASMs linear memory directly, pointer-style, which can avoid the need for serialization/deserialization - just place active data right on the "tape" and use it from either side. I took this approach in the dots demo - in ffi.rs you can see I'm returning raw pointers to memory locations, which I just access via arrays from index.js.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great post! Do you know how WASM performance compares to JS frameworks like React?
In benchmarks, it looks really good. This benchmark isn't perfect, though - it's a contrived example and the competitors are using outdated versions. There's some good discussion in this issue - including a benchmark where
yewis among the slowest measured. It turns out in that first graph Yew was skipping outright some of the calculations that were clogging up the other numbers - both a point for Yew's optimizations and against the integrity of the benchmark.The real-world story is complicated, in short. It's not a guaranteed speedup, but in a lot of cases will likely be faster than a line-for-line translation from React. The JS <-> WASM bridge is a work in progress - it's already made leaps and bounds since I started playing with Yew, but any time you cross the FFI boundary there is going to be overhead to contend with and the performance of any given app is somewhat unpredictable - there are a lot of variables.
For now, the best approach for maximum performance would be to stick to traditional frontend tools and isolate computationally heavy operations. You can abstract these hot code paths out to their own WASM modules, and organize so that there isn't a ton of data being passed back and forth. You are also able to interact with WASMs linear memory directly, pointer-style, which can avoid the need for serialization/deserialization - just place active data right on the "tape" and use it from either side. I took this approach in the dots demo - in ffi.rs you can see I'm returning raw pointers to memory locations, which I just access via arrays from index.js.