Live data from Hacker News

Debugging WebAssembly outside of the browser

hacks.mozilla.org

51–60 of 66 posts

Re: Debugging WebAssembly outside of the browser

#51
post #50

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.

> 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

Re: Debugging WebAssembly outside of the browser

#52
post #50

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.

> 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 p…

And what if the windows users?

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

Re: Debugging WebAssembly outside of the browser

#53
post #50

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.

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.

Re: Debugging WebAssembly outside of the browser

#54
post #50

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.

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.

Re: Debugging WebAssembly outside of the browser

#55
post #29

Earlier quoted context omitted.

Minor nitpick. WebKit created a debugger a couple of years before chrome existed. https://webkit.org/blog/61/introducing-drosera/

The Mozilla Suite had a javascript debugger ( 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.

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

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

Re: Debugging WebAssembly outside of the browser

#56

Earlier quoted context omitted.

> 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 t…

Contrary to popular belief, performance is always a factor. Every cycle your app wastes is a cycle another app can't use. It's a fraction of a watt that adds up over time, draining batteries faster, drawing electricity from the power grid and burning carbon fuels. Each individual cycle may be cheap, but when we have a culture of development that doesn't respect performance, the waste adds up and has a real impact on…

I don’t think a serious study of the issue can be done. Code review is the most difficult part of the development process (and a major advantage of open source), and businesses want to code the MVP as fast as possible without the competition copying them.

The ideal language isn’t the most efficient language but one that is fast to develop, and leaves a possibility to optimize later. I would think languages like Nim and Rust are best in that regard, and more recently JavaScript.

Re: Debugging WebAssembly outside of the browser

#57

Earlier quoted context omitted.

WASM embeddings like https://github.com/wasmerio/wasmer-c-api should allow that, at least calling from the embedder into WASM, and from WASM into the embedder. (e.g. see https://github.com/wasmerio/wasmer-c-api/blob/master/wasmer-... ) There's similar embeddings for other languages here (python, go, ruby etc...): https://github.com/wasmerio

I can't think of any good use cases for loading WebAssembly modules into native code. I also think it's bad out of the gates that the WebAssembly community is so fragmented across the different runtimes (each offering different functionality at the moment).

Fastly is building a WebAssembly runtime on its edge servers so customers can run their own sandboxed WebAssembly closer to clients:

https://www.fastly.com/blog/announcing-lucet-fastly-native-w...

Re: Debugging WebAssembly outside of the browser

#58

Earlier quoted context omitted.

I can't think of any good use cases for loading WebAssembly modules into native code. I also think it's bad out of the gates that the WebAssembly community is so fragmented across the different runtimes (each offering different functionality at the moment).

Think of plugins for applications like Autodesk Maya. Currently these are either cross-platform, but very slow Python plugins, or fast native DLLs which need to be compiled for each app-version/OS/CPU combination. If Maya had an embedded WASM runtime it could support plugins which are fast (at least much closer to native speed than Python scripts), and you only need to distribute a single WASM blob.

Why not just use Lua?

Re: Debugging WebAssembly outside of the browser

#59

Earlier quoted context omitted.

I can't think of any good use cases for loading WebAssembly modules into native code. I also think it's bad out of the gates that the WebAssembly community is so fragmented across the different runtimes (each offering different functionality at the moment).

Fastly is building a WebAssembly runtime on its edge servers so customers can run their own sandboxed WebAssembly closer to clients: https://www.fastly.com/blog/announcing-lucet-fastly-native-w...

Wasmer

Lucet

wasm-jit-prototype

None of them will let your WebAssembly code call an exported function from a shared library.

As an exercise, try to call https://docs.microsoft.com/en-us/windows/win32/api/winuser/n... from WebAssembly.

Re: Debugging WebAssembly outside of the browser

#60
post #55

Earlier quoted context omitted.

The Mozilla Suite had a javascript debugger ( 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.

Netscape even had a JS debugger in '97 [0]. [0] http://www.rdwarf.com/lerickson/jscript/jsd.pdf

Wow, I wish I had known that back then. How did I miss that?
Post reply on HN