WASM can do some awesome things. But what’s not awesome? Debugging with WASM. Read on to learn the limitations and recommendations!

If you know anything about WebAssembly (WASM), it’s probably that WASM lets you execute code compiled from languages such as C, C++, Rust, or others in the browser at almost native speeds. You might be less familiar with the fact that WASM is not only an interesting technology in the browser, but also in other environments that require fast sandboxing. As such, WASM has found some popularity with edge computing and as a lightweight docker replacement for certain situations.

The latter is enabled by a standard called WASI, which provides a platform-independent abstraction to interface with the operating system for basic input/output, file system access, getting the current time, and other such things. WASI is implemented by runtimes such as wasmtime or wasmer.

WASM can do some awesome things. But what’s not awesome? Debugging with WASM.

Many of us are working on complex systems where it’s increasingly difficult to reproduce real bugs. As developers, we understand this challenge. That’s why we made sure you can use Sentry’s source maps to find stack traces that reliably show what your real stack trace looked like — even on a minimized JavaScript build. And when it comes to WASM, we want to have a reliable stack trace with reliable function names, line numbers and file names in production, so we can send this to a system like Sentry. But this is where we’re running into limitations at the moment.

Current Debug Gripes

WASM at its core is quite different from many systems that native languages normally deal with. It’s a stack machine! Functions are not “addressable” in the same memory space as the memory we are working with. This “novel” concept has advantages, but much of WASM’s existing tooling is not built for our current reality.

#webassembly #wasm #web-development #developer