Usually I'm debugging a native "desktop build" of the code in VStudio or XCode since 99% of the bugs are not emscripten specific. But having said that: browsers are becoming a really good debugging platform as well. emscripten can emit source maps, which kinda lets you directly debug the C++ code in the browser (not as fluent as in a native debugger yet, since only code lines are mapped, not variables, but the potential is clear). Some WebGL related debugging tools are really good in the browser (e.g. Firefox' WebGL shader debugger or the WebGL inspector browser extension). Especially on OSX which doesn't have very good debugging tools for desktop GL the browser WebGL debugging tools are actually better then what's available as native tools (not as good as PIX or NVIDIA's NSight tool on Windows though).
Thanks! I was thinking specifically of bugs that occur in the browser target but not the native build.
Given your experience that "99% of the bugs are not emscripten specific", I'm very impressed with how emscripten can retain the semantics of the native code across the conversion and optimisation process. Obviously thats what any compiler does, but in this case the target environment seems to me to be much more complex than a physical cpu: threads, memory management, etc.
> in this case the target environment seems to me to be much more complex than a physical cpu: threads, memory management, etc.
It compiles for a restricted subset of javascript. There are no threads (there are no threads in javascript itself in the first place), and it works around memory management (it sets up big typed arrays, and memory allocations are slices of that)
