Hacker News Reader

Comment by Waterluvian | Hacker News Reader

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?

View on HN

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