[charcircuit]

JavaScript will typically have better performance than WASM. WASM is good for porting existing software to the web. So if you have tens thousands of engineering hours dumped into some game engine that engine can be brought to the web instead of having to duplicate that work with a rewrite. Using javascript apis from WASM isn't possible and requires you to do extra copies. Yes, there are optimizations that browsers can do, but it's game of catch up with the performance of javascript. Or if you want to share code between a native version of the game and the web version WASM may be good. Performance should not be the reason you pick WASM.

[flohofwoe]

> JavaScript will typically have better performance than WASM.

That's a very - erm - interesting opinion which I haven't seen elsewhere yet ;)

IME, asm.js can achieve similar performance as WASM, but not 'idiomatic' JS.

Calls from WASM into JS are fast nowadays, but they are still an optimization barrier, doing this frequently (e.g. hundreds-of-thousands times per frame) is neither recommended, nor needed (and that's about the only situation where I can imagine that pure JS might outperform WASM - and IIRC I've seen some poorly built benchmarks which showed exactly this and which then claimed that "JS is faster than WASM").

(to be clear: JS and WASM performance is closer than most people think, but JS consistently outperforming WASM is the same sort of myth like "Java is faster than C++ because a JIT has more optimization opportunities" - that might be true in theory, but not in the real world outside some fabricated benchmarks).

[peterashford]

“Preliminary results show that WebAssembly, while still in its infancy, is starting to already outperform JavaScript, with much more room to grow,”

https://thenewstack.io/javascript-vs-wasm-which-is-more-ener...

[charcircuit]

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.

[flohofwoe]

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"

[charcircuit]

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.

[flohofwoe]

> 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).