
Debugging WebAssembly outside of the browser - syrusakbary
https://hacks.mozilla.org/2019/09/debugging-webassembly-outside-of-the-browser/
======
michaelanckaert
I'm not sure if I like where this whole WebAssemby thing is going. On one hand
I'm thrilled to the prospect of Python in the browser, on the other this seems
like a huge layered mess just waiting to trouble those poor devs.

I actually enjoy creating plain server side rendered web applications with
just a dusting of client side Javascript where it makes sense. The development
flow is simple and debugging is easy.

~~~
ScottFree
WASM is still young. The tooling around it hasn't gained maturity yet. Do you
remember trying to debug Javascript before the creation of the in-browser
debugger? Desktop application developers back then probably felt the same way
you do now.

> this seems like a huge layered mess just waiting to trouble those poor devs.

WASM is a VM. It's less complicated than a javascript engine. How complicated
it seems in daily practice is going to come down to how good the tooling is.

~~~
aidos
Minor nitpick. WebKit created a debugger a couple of years before chrome
existed. [https://webkit.org/blog/61/introducing-
drosera/](https://webkit.org/blog/61/introducing-drosera/)

~~~
glandium
The Mozilla Suite had a javascript debugger ([https://www-
archive.mozilla.org/projects/venkman/](https://www-
archive.mozilla.org/projects/venkman/)) before either Webkit or Firefox
existed. I won't claim it's the first, although it might as well be.

~~~
shakna
Netscape even had a JS debugger in '97 [0].

[0]
[http://www.rdwarf.com/lerickson/jscript/jsd.pdf](http://www.rdwarf.com/lerickson/jscript/jsd.pdf)

~~~
glandium
Wow, I wish I had known that back then. How did I miss that?

~~~
shakna
Don't worry, you didn't miss much. It was as stable as most software of that
era.

~~~
aidos
Though, surely it wasn't better than the IE js debugger. "Error on line 0"

------
blaisio
I'm not a fan of seeing web assembly spread outside the browser. If you want
to sandbox binary code, there are many much more efficient options, eg. Linux
containers (especially with tools like gvisor) or VMs. Vendors that only allow
use of WebAssembly are leaving performance and compatibility on the table.

~~~
CharlesW
> _If you want to sandbox binary code, there are many much more efficient
> options, eg. Linux containers (especially with tools like gvisor) or VMs._

WebAssembly is a VM, with an accompanying instruction format.[1]

> _Vendors that only allow use of WebAssembly are leaving performance and
> compatibility on the table._

It'd be interesting to know what you're thinking of when you say that. For
example, is Cloudflare leaving performance and compatibility on the table by
using WebAssembly instead of Linux containers for Cloudflare Workers?

[1]
[https://en.wikipedia.org/wiki/WebAssembly#Stack_machine](https://en.wikipedia.org/wiki/WebAssembly#Stack_machine)

~~~
chii
And what if the windows users?

Webassembly is a perfectly good container and would by default have
crossplatform capability.

~~~
pjmlp
Just like when I deploy Jars compiled on Windows across Linux servers,
amazing!

------
jore
Looks interesting, but why would I need to debug wasm binaries when I could
debug directly the rust code? And why would I want to convert it to wasm? In
order to run it in the browser, right?

~~~
lmkg
I don't see how you would "debug directly the rust code" without debugging the
wasm binaries. Wasm is a compilation target for rust. To be clear: You compile
rust directly to wasm, it's not like you compile your rust to a binary and
then convert that to wasm. I do not believe there is an intermediate artifact.

As for your second question... there's motion towards making wasm runtimes
other environments, like devices or server-side. Kind of like the JVM or CLR,
but closer to the metal (e.g. no garbage collector). The advantage of the
server-side is the same as node.js, sharing code with the client. The
advantage for other environments is a portable file format with performance
characteristics closer to native. My impression is that the reception is less
enthusiastic than wasm in the browser.

~~~
flohofwoe
> I don't see how you would "debug directly the rust code"

I think the intention of OP is that you compile the same Rust code to a native
x86 or ARM binary and debug that. Most bugs are ISA-agnostic so that approach
totally makes sense in many situations.

That's how I'm debugging my WASM code compiled from C/C++, and that also works
automatically with IDE debuggers that don't know about WASM (like Xcode's or
Visual Studio's).

~~~
kodablah
While that can work with self-contained libs, quite often Rust WASM code uses
wasm-bindgen/web-sys to talk to JS/DOM which makes in-browser debugging the
only reasonable way.

~~~
ScottFree
Flash and Java allowed you to run the code in the browser, but still debug
using the source code and not the VM bytecode.

~~~
AgentME
A good wasm debugger would let you see the source code too, just like how
regular native debuggers show you the source code instead of x86 assembly.

------
tambourine_man
I gotta say, that's something I'm not looking forward to

------
ori_b
Looks like we're well on our way to a somewhat overly complicated
reimplementation of thin binaries[1]

[1]
[http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108...](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.1711&rep=rep1&type=pdf)

~~~
saagarjha
We had that already with the JVM and CIL. They never caught on in the browser.

~~~
coldtea
No, we had a VM / runtime environment with those. Now it's much closer to the
metal.

~~~
yellowapple
The more relevant improvement is that it's better-integrated with the browser;
Java and Silverlight both had pretty horrendous user experiences (and the
latter wasn't even usable outside Windows without hacking Wine/Mono into a
browser plugin, e.g. Pipelight).

The sandboxing story also seems to be much stronger with WASM than either of
those (where sandboxing felt more like an afterthought at best).

In other words: WASM still relies on a runtime/VM, but the difference is that
the runtime/VM is astronomically better for the intended use case (and also,
incidentally, a presumably-unintended use case) than most existing
runtimes/VMs.

------
hackcasual
I think the title on this would be more clear if it was the full article
title, "Debugging WebAssembly Outside of the Browser."

~~~
dang
Fixed now.

