Hacker News Reader

Comment by davexunit | Hacker News Reader

This type of comment shows up on seemingly every thread about wasm and it is so tiresome. Wasm can't do any I/O unless the host passes the module a capability to do so. If you pass a module some DOM functions then it can access the DOM.

View on HN

I’m curious though, does it gain meaningful access to the DOM in the case you described, or is it more just a proxy where it’s asking javascript, via some sort of channel, to manipulate the DOM?

It's a bit between the two, really. There are typically still JavaScript helpers in the middle, but not for the reason most people think. The remaining reason is that Wasm cannot perform JavaScript method calls (with a receiver object). It can only perform function calls (without receiver). So you need JavaScript helpers in the middle to translate between a calling convention that doesn't use `this`, only regular parameters, to another convention where one of those parameters becomes the receiver of a method call.

Then that main reason has a number of declinations, like no JavaScript `new`, no field selection, etc. But you can work around all these things with similar "calling convention conversions".

Maybe more importantly for performance, are those helpers inlinable into wasm?

At least in V8, wasm is handled by the same internals as javascript is. Its processed by the same optimization passes and turned into machine code by the same backend which generates the machine code for js.

While I'm not sure how much cross-language optimization is being done, it sounds like these all reduce to the same concepts in the end and I don't think the performance impact will be as large as you think.

Reply on news.ycombinator.com