6 comments

[ 3.1 ms ] story [ 19.8 ms ] thread
Very useful. It would be great for the browser become the cross-platform application target. I've been eagerly waiting for Qt WebAssembly to mature.
Is anyone using Qt for developing Mac apps these days? How is the integration after the recent Mac UI refresh?
I feel like this article is severely flawed.

Debugging wasm qt apps is not hard at all. Yes, as the article says, you need to build the code in debug mode, this isn’t unusual.

If you use qtcreator, it’s, and I hate this word, trivial. Most of the work comes from setting up the qt kit in qtcreator… which takes about 5 minutes.

Breakpoints just work. Debugging just works. Everything… works.

What's interesting here is that you can now debug WebAssembly applications with full C++ source-level debugging directly in Chrome, complete with breakpoints, variable inspection, and step-through debugging, just like a native desktop app.

What makes this particularly interesting is the technology stack: Emscripten embeds DWARF debugging symbols (the same format used for native Linux binaries) directly into WebAssembly binaries. A Chrome browser extension then reads these embedded symbols and reconstructs the original C++ source code view in the DevTools, mapping the compiled WebAssembly back to your Qt C++ source with full directory paths intact.

All of this would have seemed impossible not long ago.

In VSCode it's quite a bit more convenient since you don't need to faff around with Chrome extensions or the browser dev tools and debugging happens right in VSCode.

It still requires some tinkering with launch.json to glue a couple of VSCode extensions together though, but the result is that I can simply press F5 in VSCode to step into my C/C++ code with the debuggee running remotely in Chrome - e.g. exactly the same workflow like a native debug session:

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

I wish licensing restrictions weren't holding back more widespread adoption of qt wasm.