[MrResearcher]

That still requires the usage of dev tools and linear source code mapping between the original and the generated WASM, correct? Would it be possible to avoid dev tools, and implement the debugger in Javascript? Or the WASM technology doesn't provide such an opportunity? I'd like to break on breakpoints, jump back into Javascript, unroll it into the original location in the source code, and display it all in an IDE-like window all within a browser page, and without involvement of dev tools (that can't handle non-linear conversions between source code and generated JS/WASM).

[titzer]

Yes, if you use bytecode rewriting then all the offsets are changed and you need a mapping. This is one of the advantages of engine-side instrumentation; bytecode offsets don't change. It'll be some time before we can get engines to agree on a standard interface for instrumentation, but there have been some discussions.

Whamm can inject arbitrary instrumentation logic, so you could, e.g. inject calls to imports that are implemented in JS. You'll have some heavy lifting to do on the JS side.

[gwbas1c]

Visual Studio supports debugging C# compiled to WASM when your page is made with Blazor.

Granted, you're debugging in another window that isn't a browser; but overall the debugger is about 80% of what you get when debugging a .net process running outside of the debugger.