If I'm right, we won't see wasm overused such that the web becomes a sea of monolithic and opaque apps (as too many mobile OS homescreens are). Per the FAQ, wasm is also for hot kernel code and reusable libraries helping mostly-JS apps.
It's up to web devs to keep innovating ahead of browsers, to keep pushing for better HTML, CSS, JS, and beyond. One way to do this might be via wasm modules that extend the web. The https://extensiblewebmanifesto.org/ project continues.
I think the only way the web could remain mostly-JS apps, is if the benefits of writing mostly-JS apps would outweigh the benefits of writing, well, not-mostly-JS apps.
And I'm not sure if that's gonna be true.
For example, I'm sitting here, arguing for an open and readable web, and yet I can't wait for a rust-to-asm.js workflow to get stable enough so that I can move the perf-critical parts of my app to rust (you know, the part that could be learned from and hacked on by another developer).
Serious question: why could not those other devs learn from your Rust code, even decompile wasm back into it via their devtools and ye olde view source?
Because the source-map may not be available. And they might not know Rust. Or perhaps having to setup a Rust dev env to play with this code is too much work and it's just not worth it.
I'm suggesting that when debugging optimized code, you'll use -g as on native platforms. I'm speculating further that with wasm, decompilers will rise to the view source challenge.
If I'm right, we won't see wasm overused such that the web becomes a sea of monolithic and opaque apps (as too many mobile OS homescreens are). Per the FAQ, wasm is also for hot kernel code and reusable libraries helping mostly-JS apps.
It's up to web devs to keep innovating ahead of browsers, to keep pushing for better HTML, CSS, JS, and beyond. One way to do this might be via wasm modules that extend the web. The https://extensiblewebmanifesto.org/ project continues.