One thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS

One thing is pure call performance (time to invoke a void() function). I don't know where that is, but I guess for WASM<->JS it's slower than WASM<->WASM and JS<->JS, since it can't be inlined. The more important thing however is the cost of parameter passing. Let's keep in mind that WASM only support numeric types and typed arrays. So in order to make a function call from JS to WASM or the other way around which passes a string as a parameter the string needs to be converted into a format that the other side understands (Javascript string object <-> WASM typed array which contains string in UTFx format). So basically for all more complex data types crossing the boundary costs the [de]serialization of the parameters, which may be huge (and even causes allocations). If you also only work with integers and typed arrays on the JS side that does not apply. But I guess most people won't be comfortable with that.