Hacker News new | past | comments | ask | show | jobs | submit login

I would like to see this done with JavaScript that is an actual game or application. A gameboy emulator is a virtual machine and is not heavy on IPC with the DOM. Measuring a C++ program compiled into JavaScript (C virtual machine) doesn't seem representative either.

The paper more shows that if you are building a virtual machine in the browser you should use WASM. I agree that is a sensible choice.




The calling overhead from WASM into JS in order to talk to browser APIs is usually negligible compared to the actual cost of the called function.

Also see this article from 2018: https://hacks.mozilla.org/2018/10/calls-between-javascript-a...

Quote: "calls between JS and WebAssembly are faster than non-inlined JS to JS function calls"


The problem is that these function only work with numbers. If you are trying to use functions that take or return objects or strings you start running into trouble.

So either you end up making a JavaScript engine that does all of the heavy work in regards to interfacing with the browser (including APIs like webgpu) or you come up with some serialization scheme to allow for wasm to work with these functions.

My point is that if you are making a big chunk of JavaScript already there is a benefit to just doing most of everything else with JavaScript if you can get away with it. I'm not trying to claim that in all circumstances WASM will be slower and I will encourage people to check for themselves, but I will stand behind the claim that performance should not be the reason you choose to make your web application with WASM.


> performance should not be the reason you choose to make your web application with WASM

This I can mostly agree with, but it's a slightly different take than "JS is faster than WASM" though ;)

The marshalling for 'non-trivial types' (like strings or data structures) can indeed be a performance problem, but quite often one can get away with just passing numbers between the JS and WASM side. I'm actually a bit disappointed that WebGPU turned out so 'object-oriented' (e.g. most WebGPU objects are actual Javascript objects instead of 'number-handles'), which means that a lookup-table needs to be maintained on the JS side (I think that's what the externref proposal is supposed to solve).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: