16 ms·

Debugging WebAssembly outside of the browser

140 points by syrusakbary 7y ago

hackcasual 7y ago
I think the title on this would be more clear if it was the full article title, "Debugging WebAssembly Outside of the Browser."
- dang 7y ago
  Fixed now.
deleted 7y ago
[deleted]
ori_b 7y ago
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.1711&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108...
- saagarjha 7y ago
  We had that already with the JVM and CIL. They never caught on in the browser.
  - coldtea 7y ago
    No, we had a VM / runtime environment with those. Now it's much closer to the metal.
    - yellowapple 7y ago
      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.
jore 7y ago
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?
- michielderhaeg 7y ago
  What if your code is browser specific and uses the javascript based API? You'll need to run it in the browser to debug it right?
  - callahad 7y ago
    Yep! We're still working on how in-browser debugging should work, but we'll get there. This post is specifically "Debugging WebAssembly Outside of the Browser," but the title on HN was unfortunately truncated.
- flohofwoe 7y ago
  For bugs that only manifest when compiled to WASM but not when compiled to x86 or ARM machine code (quite rare, but happens), or bugs in platform-specific code (for instance code which talks to browser APIs). In typical applications, the vast majority of bugs should happen in the platform-agnostic parts, so debugging a native build totally makes sense. It would still be great if WASM would be as trivially debuggable as native code. IMHO proper source-level debugging support in the browser dev-tools (or remote-debugging via VSCode) would make a lot more sense than debugging in gdb/lldb though.
- lmkg 7y ago
  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.
tambourine_man 7y ago
I gotta say, that's something I'm not looking forward to
michaelanckaert 7y ago
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.
- k__ 7y ago
  I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. But well, I guess people will do it anyway, let's see how this plays out in the long run.
  - josteink 7y ago
    > I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing. This was one of the key features and benefits of NodeJS, and I won’t be surprised when I see others trying to replicate the experience via web-assembly.
    - k__ 7y ago
      I think the USP of Node.js was that the majority of devs already knew JS. What I want to say is, I question the premise that there are as many backend devs who just don't do frontent stuff because of JS as there were frontend devs who didn't do backend because JS wasn't an option. On the other hand the industry gets bigger by the day, maybe even a small percentage of devs doing Python frontends will be thousands of people :)
      - MuffinFlavored 7y ago
        How long until the industry doesn't get bigger by the day, and frontend devs + backend devs alike get automated away when AI can generate maintainable + readable code for 95% of the "API + UI plumbing" that is out there?
blaisio 7y ago
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 7y ago
  > 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 7y ago
    And what if the windows users? Webassembly is a perfectly good container and would by default have crossplatform capability.
    - pjmlp 7y ago
      Just like when I deploy Jars compiled on Windows across Linux servers, amazing!
- gravypod 7y ago
  Would you say the same about the JVM, JavaScript (SpiderMonkey + V8), RVM, cPython, and other bytecode VMs? I don't see how a bytecode VM leaves performance and compatibility on the table. If anything, from the JVM standpoint, the JIT features and platform separation improve performance and stability.
- kentonv 7y ago
  VMs might be more "efficient" in some ways but certainly not all ways. If you want to run 10,000+ sandboxes on a machine, you can do it with WebAssembly. With (hardware virtualization) VMs it would be rough.

140 points by syrusakbary 7y ago

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

dang 7y ago
Fixed now.

deleted 7y ago

[deleted]

ori_b 7y ago

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.1711&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108...

saagarjha 7y ago
We had that already with the JVM and CIL. They never caught on in the browser.
- coldtea 7y ago
  No, we had a VM / runtime environment with those. Now it's much closer to the metal.
  - yellowapple 7y ago
    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.

jore 7y ago

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?

michielderhaeg 7y ago
What if your code is browser specific and uses the javascript based API? You'll need to run it in the browser to debug it right?
- callahad 7y ago
  Yep! We're still working on how in-browser debugging should work, but we'll get there. This post is specifically "Debugging WebAssembly Outside of the Browser," but the title on HN was unfortunately truncated.
flohofwoe 7y ago
For bugs that only manifest when compiled to WASM but not when compiled to x86 or ARM machine code (quite rare, but happens), or bugs in platform-specific code (for instance code which talks to browser APIs). In typical applications, the vast majority of bugs should happen in the platform-agnostic parts, so debugging a native build totally makes sense. It would still be great if WASM would be as trivially debuggable as native code. IMHO proper source-level debugging support in the browser dev-tools (or remote-debugging via VSCode) would make a lot more sense than debugging in gdb/lldb though.
lmkg 7y ago
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.

tambourine_man 7y ago

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

michaelanckaert 7y ago

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.

k__ 7y ago
I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. But well, I guess people will do it anyway, let's see how this plays out in the long run.
- josteink 7y ago
  > I think the plan was to get high performance stuff into the browser, with languages like C/C++ and Rust and not to replace JS with Python, C# or Java. On the contrary, for many people performance isn’t a factor, but they find the idea of using the same language (and thus code) client-side and server-side appealing. This was one of the key features and benefits of NodeJS, and I won’t be surprised when I see others trying to replicate the experience via web-assembly.
  - k__ 7y ago
    I think the USP of Node.js was that the majority of devs already knew JS. What I want to say is, I question the premise that there are as many backend devs who just don't do frontent stuff because of JS as there were frontend devs who didn't do backend because JS wasn't an option. On the other hand the industry gets bigger by the day, maybe even a small percentage of devs doing Python frontends will be thousands of people :)
    - MuffinFlavored 7y ago
      How long until the industry doesn't get bigger by the day, and frontend devs + backend devs alike get automated away when AI can generate maintainable + readable code for 95% of the "API + UI plumbing" that is out there?

blaisio 7y ago

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 7y ago
> 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 7y ago
  And what if the windows users? Webassembly is a perfectly good container and would by default have crossplatform capability.
  - pjmlp 7y ago
    Just like when I deploy Jars compiled on Windows across Linux servers, amazing!
gravypod 7y ago
Would you say the same about the JVM, JavaScript (SpiderMonkey + V8), RVM, cPython, and other bytecode VMs? I don't see how a bytecode VM leaves performance and compatibility on the table. If anything, from the JVM standpoint, the JIT features and platform separation improve performance and stability.
kentonv 7y ago
VMs might be more "efficient" in some ways but certainly not all ways. If you want to run 10,000+ sandboxes on a machine, you can do it with WebAssembly. With (hardware virtualization) VMs it would be rough.