3 ms·

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web A

What is the meaningful difference between WASM/JS interop and WASM/Web-API interop? Implicit importing of them all? There are host bindings coming [0]. If Web APIs are expressed in terms of JS and you want interop with them, you use what they are expressed in. Or are you saying Web APIs should be available in WASM terms (which is harder due to lack of structural, array, string, null, etc types)? 0 - https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md https://github.com/WebAssembly/host-bindings/blob/master/pro...

jdc 8y ago
Performance
- kodablah 8y ago
  One might expect that never leaving the WASM context and interoperating with browser APIs, even if defined in JS terms, would not incur JS penalties. Granted it may affect JS argument validation. But this requires representation of those types. For example, if the DOM API allows searching for a selector which is a string, how do you build that string in WASM and how do you pass it? You'd use host refs anyways I would guess, essentially creating a new host "string" which is meaningfully equivalent to creating a JS string.
cm2187 8y ago
I’d assume you would get a performance (and therefore battery) benefit by not maintaining a js layer, though a js layer is a perfectly acceptable temporary solution.
- lj3 8y ago
  Careful. Javascript was a perfectly acceptable temporary solution too. Temporary solutions have a way of becoming permanent.
marcosdumay 8y ago
The difference is being able to serve some WASM script that interacts with your page without having to send and entire glibc equivalent. In practice, that means having an standard library on browsers that you can call in a standard idiom.
- fulafel 8y ago
  Dead code elimination in your compiler should be taking care of this, no?
ecnahc515 8y ago
It would kind of be like defining a set of syscalls that anything targeting WASM could use. Right now, JS interop is sorta like being given a DLL that requires an entire JS runtime to support it, whereas direct Web-API interop would mean there is no JS runtime requirement IIRC.

jdc 8y ago

Performance

kodablah 8y ago
One might expect that never leaving the WASM context and interoperating with browser APIs, even if defined in JS terms, would not incur JS penalties. Granted it may affect JS argument validation. But this requires representation of those types. For example, if the DOM API allows searching for a selector which is a string, how do you build that string in WASM and how do you pass it? You'd use host refs anyways I would guess, essentially creating a new host "string" which is meaningfully equivalent to creating a JS string.

cm2187 8y ago

I’d assume you would get a performance (and therefore battery) benefit by not maintaining a js layer, though a js layer is a perfectly acceptable temporary solution.

lj3 8y ago
Careful. Javascript was a perfectly acceptable temporary solution too. Temporary solutions have a way of becoming permanent.

marcosdumay 8y ago

The difference is being able to serve some WASM script that interacts with your page without having to send and entire glibc equivalent. In practice, that means having an standard library on browsers that you can call in a standard idiom.

fulafel 8y ago
Dead code elimination in your compiler should be taking care of this, no?

ecnahc515 8y ago

It would kind of be like defining a set of syscalls that anything targeting WASM could use. Right now, JS interop is sorta like being given a DLL that requires an entire JS runtime to support it, whereas direct Web-API interop would mean there is no JS runtime requirement IIRC.