[lmkg]

I don't see how you would "debug directly the rust code" without debugging the wasm binaries. Wasm is a compilation target for rust. To be clear: You compile rust directly to wasm, it's not like you compile your rust to a binary and then convert that to wasm. I do not believe there is an intermediate artifact.

As for your second question... there's motion towards making wasm runtimes other environments, like devices or server-side. Kind of like the JVM or CLR, but closer to the metal (e.g. no garbage collector). The advantage of the server-side is the same as node.js, sharing code with the client. The advantage for other environments is a portable file format with performance characteristics closer to native. My impression is that the reception is less enthusiastic than wasm in the browser.

[flohofwoe]

> I don't see how you would "debug directly the rust code"

I think the intention of OP is that you compile the same Rust code to a native x86 or ARM binary and debug that. Most bugs are ISA-agnostic so that approach totally makes sense in many situations.

That's how I'm debugging my WASM code compiled from C/C++, and that also works automatically with IDE debuggers that don't know about WASM (like Xcode's or Visual Studio's).

[kodablah]

While that can work with self-contained libs, quite often Rust WASM code uses wasm-bindgen/web-sys to talk to JS/DOM which makes in-browser debugging the only reasonable way.

[ScottFree]

Flash and Java allowed you to run the code in the browser, but still debug using the source code and not the VM bytecode.

[AgentME]

A good wasm debugger would let you see the source code too, just like how regular native debuggers show you the source code instead of x86 assembly.