[josephg]

How would a compiler toolchain ship a debugger for webassembly? It’s kind of impossible. The only place for a debugger is inside the browser. Just like we do now with dev tools, JavaScript, typescript and webassembly languages.

> The browser is already complex enough as it is and should be radically stripped down

I’d love this too, but I think this ship has sailed. I think the web’s cardinal sin is trying to be a document platform and an application platform the same time. If I could wave a magic wand, I’d split those two used cases back out. Documents shouldn’t need JavaScript. They definitely don’t need wasm. And applications probably shouldn’t have the URL bar and back and forward buttons. Navigation should be up to the developers themselves. If apps were invented today, they should probably be done in pure wasm.

> Web APIs are designed from the ground up for Javascript

Web APIs are already almost all bridged into rust via websys. The APIs are more awkward than we’d like. But they all work today.

[azakai]

> How would a compiler toolchain ship a debugger for webassembly?

You can integrate external debuggers, like Uno documents here:

https://platform.uno/docs/articles/debugging-wasm.html

I assume that uses some browser extension, but I didn't look into the details.

You can also use an extension to provide additional debugging capability in the browser:

https://developer.chrome.com/docs/devtools/wasm

[flohofwoe]

FWIW, it's possible to setup an IDE-like debugging environment with VSCode and a couple of plugins [1]. E.g. I can press F5 in VSCode, this starts the debuggee in Chrome and I can step-debug in VSCode exactly like debugging a native program, and it's even possible to seamlessly step into JS and back. And it's actually starting faster into a debug session than a native macOS UI program via lldb.

[1] https://floooh.github.io/2023/11/11/emscripten-ide.html

[pjmlp]

Inside the browser hardly matters if it isn't maintained, Google has done almost nothing to their DWARF debugging tooling since it was introduced as beta a few years ago.

[flohofwoe]

> Google has done almost nothing to their DWARF debugging tooling since it was introduced as beta a few years ago

WASM DWARF debugging works perfectly fine though?

The 'debugger half' just moved from Chrome into a VSCode debug adapter extension where debugging is much more comfortable than in the browser:

https://marketplace.visualstudio.com/items?itemName=ms-vscod...

I use that all the time when working on web-platform specific code, with this extension WASM debugging in VSCode feels just like native debugging (it actually feels snappier on macOS than debugging a native macOS exe via LLDB).

[pjmlp]

More like it mostly works.

[flohofwoe]

...'mostly works' describes pretty much every debugging experience outside Visual Studio. But I really can't complain, I've set up 'F5-debugging' in VSCode, pressing F5 starts a local web server, starts Chrome with the debuggee, and starts a remote debug session in VSCode and stops at the first breakpoint (and interestingly all this happens 'immediately', while debugging a native Cocoa macOS app via LLDB easily takes 5 to 10 seconds until the first breakpoint is reached).

TL;DR: It works just fine (early versions of the DWARF extension had problems catching 'early breakpoints' but that had been fixed towards the end of 2024.