Isn't debugging just a short interation away from being like native debugging? You get a source map, you see C++ in the devtools with C++ variables and a C++ call stack and an option to "view webassembly"
I have to assume the browser teams are working on this
That might work well enough for C++, but I'm not sure how well it would work for other languages. For example, apparently gdb doesn't work all that well for debugging Go programs?
Each language has its own peculiarities for how objects are represented on the heap.
To be fair, a generational mark-sweep GC algorithm doesn't take much more space over the compile-time modifications to the code itself. A reasonably performant GC algorithm suitable for most front-end work would probably only add about 10 kilobytes to 20 kilobytes of code to an executable. That can be downloaded and cached in the blink of an eye.
Re:What makes WebAssembly fast?
by imtringued on Wednesday March 01, 2017 @04:26AM
(#13762461)
The problem is that you need to get all the GC root nodes on the stack. This is platform specific and must be implemented by the browser. The only crossplatform way is to create an additional shadow stack that contains only the root nodes but this means you pay an additional cost for the GC on every function invocation.
That would only be required for data on the GC heap. Yes, you would have to implement an FFI for communicating with the browser, especially for any callbacks into the browser that take allocated memory, but it is far better to build a hygienic FFI if you want to use a GC language than re-architect the browser with GC support.
It can be done. There may be pain, but the pain can be managed.
EDIT: by that I mean that one would need to maintain two heaps. One for data that interacts with the browser and that is wrapped by the FFI as external resources, and one for the internal system itself, which can be managed via GC. Only the WebAssembly code would have to manage GC roots, which can be done as per any GC language.
Garbage collection is coming to WebAssembly.
For people who don't want to use JavaScript (they are using a different source ecosystem), compile-to-WebAssembly toolchains will be in direct competition with compile-to-JavaScript toolchains. It's not at all clear which ones will win. It may be different for each language.
For C++ and Rust I'd expect WebAssembly will perform well, since it fits these languages' runtime model better. But for garbage-collected languages, compiling to JavaScript may result in smaller and faster code, since you can reuse JavaScript's runtime instead of downloading it. There may not be any reason for Elm or Dart (for example) to replace a compiler that works well with one that targets WebAssembly. Or if you like Go, I'd at least try out GopherJS before thinking you need a whole new toolchain.
It's not just performance, either. Generating somewhat-readable JavaScript that you can debug using Chrome Devtools when something goes wrong is a pretty nice advantage.