No, yew.rs does not address this problem (WASM can't directly touch the DOM or other browser APIs such as WebGPU, only JS can) It just wraps around calls to JS.
Everytime you use yew.rs or some other "pure rust" or whatever framework, it's making tons of JS calls under the hood.
This is OK for some purposes, but if you're trying for performance on a workload that isn't CPU-bound, it sucks. And it's another abstraction layer that's bound to leak, I imagine.
This is a significant issue with WASM that a lot of us are waiting with bated breath to be fixed. We want to really be able to target the web browser with NO javascript involved.
> WASM can't directly touch the DOM or other browser APIs such as WebGPU
And that's a good thing. Both APIs (DOM and to a lesser extent WebGPU) are built on top of the Javascript object model. Trying to map the JS object model to WASM inside the WASM spec would be a really bad idea.
> This is a significant issue with WASM
It's a non-issue really, brought up again and again by people who didn't really look into WASM in detail yet and what it is good for (hint: not to replace the HTML+CSS+JS combo).
The DOM is so slow to begin with that going through a (potentially automatically generated) Javascript shim from WASM wouldn't move the performance needle.
For APIs like WebGPU it would make more sense to have a WASM-friendly API, but that's really a design wart of WebGPU's Javascript API (WebGL actually did a slightly better job there). And besides, the overhead of calling from WASM into web APIs is mostly negligible compared to the overhead that happens inside the API (speaking specifically of WebGL and WebGPU here from my own experience).
1) Optimising an application for page load speed is affected by the layers of thunking.
For one thing, when a browser does the initial load of the page html, it scans for <script> tags, downloads all of them in parallel and does some preemptive compilation while preserving the declaration order for actual evaluation.
WASM modules do not receive that same optimisation because they are loaded during JavaScript evaluation, meaning the browser cannot know they exist until the JavaScript is evaluated forgoing their ability to be optimised ahead of time.
Perhaps some level of optimisation is available through the use of service worker, but it's unlikely that the initial load will be as fast in this context as there is additional overhead associated with establishing a SW and a SW only interacts with the network layer so AOT compilation optimisations will be unavailable.
2) Tooling
One of the areas of promise for WASM driven web applications was being able to exclusively use the tooling of the language you're consuming. The reliance on JavaScript for WASM modules inherently relies on the wild world of JavaScript tooling.
Personally, I have many esoteric use cases that require access to DOM APIs but no access to GUI (third party scripts sandboxed within an iframe for consumption). These use cases _must_ be optimised for initial page load. I have experimented with using Rust for my use case and, while it is faster during runtime, the initial load is slower.
3) Extras I'd like to see
I would love it if I could embed html (as a sort of manifest) within the wasm module such that the browser could use wasm as an entry point - removing the need to load html first, then wasm. As good as http2 multiplexing is, for whatever reason, loading html +1 file is slower than loading html with the application embedded within the file.
I'd also like to see us eliminate the need for the `Cross-Origin-Opener-Policy: same-site` and `Cross-Origin-Embedder-Policy: require-corp` headers as they make multi threading in the browser largely impractical.
> is evaluated forgoing their ability to be optimised ahead of time.
...not sure what you mean with that, but WASM isn't actually AOT compiled in browsers anymore, instead there are several tiers of JIT-ting on a per function level. E.g. when a WASM function is only called once it is compiled quickly but without optimization, and then when called more frequently, higher compilation tiers will kick in which compile the WASM function in the background with more optimizations.
This is pretty much the same strategy as used with Javascript code.
You can also split your WASM code into several dynamically loaded modules (and if neeeded, loaded and instantiated in parallel), but (AFAIK) unlike with Javascript bundlers this can't be done automatically. You'll have to design your code that's compiled to WASM from the ground up for being split into several modules (similar to how DLLs are used in native code).
> The reliance on JavaScript for WASM modules inherently relies on the wild world of JavaScript tooling.
I write all my WASM code with C/C++ tooling only, no npm or similar involved. There's only a minimal .html file which defines how a WebGL/WebGPU canvas integrates with the browser environment.
> I'd also like to see us eliminate the need for the `Cross-Origin-Opener-Policy: same-site` and `Cross-Origin-Embedder-Policy: require-corp` headers as they make multi threading in the browser largely impractical.
