[fsloth]

"The "universal" nature of WebGPU with the "web" focus feels a lot like the graphics API equivalent of WASM"

Having shipped non-trivial WASM code in two projects That's not a positive thing. WASM is stuck in zone between living and the dead - just good enough (barely) to merit creating production code when you need the perf in browser but not good enough to register as industrial quality tool as it's not possible really to debug a WASM application.

If you really, really need the perf in your browser app, WASM may be the only option, but it's not really a good one.

[pjmlp]

> That's not a positive thing.

Quite right.

After 15 years, browsers vendors still don't care about 3D APIs on the developer tools, you need to have a native version and hope that the issue is actually on your code and not something that the browser does.

Because of its nature and the browser sandbox, you have no idea if the application is actually working on customer browsers, or even be able to have workarounds like on native APIs.

Finally it lags a decade behind hardware capabilities being surfaced on the API.

However there is nothing else on the browser.

The only positive thing is being 3D APIs designed with managed languages in mind.

[bobajeff]

Actually, at least on Chromium it's possible to use Dwarf debugging symbols in debugging your wasm files. It's a little tricky because the documentation isn't that clear but I've ran programs through that and it works. Also there a vscode extension (which I prefer over using vs the browser devtools). If you have that it's basically like using any other debugger in vscode (including CodeLLDB) only you launch the browser when you're debugging it.

[flohofwoe]

> as it's not possible really to debug a WASM application

...as others have said, this is a solved problem and has been for quite a while:

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

I might even go that far and say that this solution is on average more robust and more responsive than debugging native code in Xcode.

[fsloth]

Hmm I never could get the DWARF debug information to hook up properly, must give this a try next time I need to return to the topic.

If you don't mind - what's your specific setup when debugging Sokol, I might start from replicating that workflow?

[flohofwoe]

Basically this, just with code-generated launch.json which starts a regular node https server (eg fewer extensions needed than in this blog post):

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

[pjmlp]

> Last updated 27/09/2023

And only "works" for specific languages.

[flohofwoe]

The extension is "feature complete" and works. Why should it need updates when it's not broken?

It should also work for all compiler toolchains that generate DWARF debug info, which is pretty much standard across all compiled languages, otherwise gdb or lldb couldn't be used either with those languages (Microsoft of course does its own thing, as is tradition, but its not like msvc supports wasm output in the first place - Blazor oth appears to support wasm debugging in VS and VSCode)

[pjmlp]

Microsoft isn't the only platform doing its own thing, although this is irrelevant for this specific case.

Given how bad most of WebAssembly tooling still is to this day, versus native languages, I was kind of sceptic.

[godwinson__4-8]

Idk maybe you were working on far more complex things but personally I didn't feel this way.

Then again perhaps the devx was just not as bad as I expected given how often I had heard this warning.