Wumpus Season
In this post series we'll walk through recreating the classic Hunt the Wumpus game in Yew. The original was played at the...
For further actions, you may consider blocking this person and/or reporting abuse
Failed hitting the big button.
Replaced dependencies as displayed below.
conflicting implementations of traityew::Renderable` for typeThe fix is to replace in Cargo.toml
[dependencies.yew]git = "https://github.com/DenisKolodin/yew"
with
[dependencies.yew]yew = "0.9.2"
Yikes, sorry I missed this! Thanks for the fix, I definitely had some issues with Cargo versioning while writing this post. Glad the stable version number works, editing the post.
These days yew doesn't recommend stdweb.
I slightly modified your code to be able to build it with wasm-pack
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.
Everything worked until I inserted the rollup.config.js file into my app & tried to run it with yarn prod
Ah, thanks for catching this! A dependency went out of date. I'm pushing fixed versions to the repo, for now you can use these deps, it worked for me now:
I'll update the post too.
Unless your problem wasnt
Was it something else?