Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
1–9 of 9 posts
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#2The real issue is that you cannot access the DOM via WASM.
Also the previous article is here[0].
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#3The real issue is that you cannot access the DOM via WASM. Also the previous article is here[0]. [0]: https://news.ycombinator.com/item?id=37849310
That doesn’t really have anything to do with this article which is about running JS quickly on server wasm runtimes.
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#4The real issue is that you cannot access the DOM via WASM. Also the previous article is here[0]. [0]: https://news.ycombinator.com/item?id=37849310
Can you explain this a little more? This is for running JS server side right? So why would there be a DOM? Is the issue that JS libraries or other things you would be using assume a DOM?
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#5The real issue is that you cannot access the DOM via WASM. Also the previous article is here[0]. [0]: https://news.ycombinator.com/item?id=37849310
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.
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#6The real issue is that you cannot access the DOM via WASM. Also the previous article is here[0]. [0]: https://news.ycombinator.com/item?id=37849310
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.
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?
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#7Earlier quoted context omitted.
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.
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".
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#8Earlier quoted context omitted.
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 par…
Maybe more importantly for performance, are those helpers inlinable into wasm?
Re: Compilation of JavaScript to WASM, Part 2: Ahead-of-Time vs. JIT
#9Earlier quoted context omitted.
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 par…
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.