4 ms·

According to Mozilla : "There are future plans to allow WebAssembly to call Web APIs directly.". https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts

by yarg 8y ago

According to Mozilla : "There are future plans to allow WebAssembly to call Web APIs directly.". https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... Although I couldn't actually find any description of the intended capabilities.

austincheney 8y ago
MDN has a page for that as well: https://developer.mozilla.org/kab/docs/Web/API https://developer.mozilla.org/kab/docs/Web/API The page DOM is not listed there. The closet thing is DOMParser which will allow parsing of an XML/HTML island into a new DOM object. https://developer.mozilla.org/kab/docs/Web/API/DOMParser https://developer.mozilla.org/kab/docs/Web/API/DOMParser
- steveklabnik 8y ago
  What you're missing is https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md https://github.com/WebAssembly/host-bindings/blob/master/pro...
  - austincheney 8y ago
    I believe you are over thinking this bullet point: > Ergonomics - Allow WebAssembly modules to create, pass around, call, and manipulate JavaScript + DOM objects That would allow WASM functionality similar to behavior already present in the browser, but that page does not say where that behavior will occur. Given this is an update to WASM it will likely occur against WASM artifacts. An example would be allowing a WASM application instance to create JavaScript event bindings and DOM artifacts on an internal DOM tree. It is wishful thinking that an update to WASM would modify the web environment outside of WASM.
    - steveklabnik 8y ago
      I think I’m just really confused as to what you’re saying. In the browser, you will be able to manipulate the browser DOM directly from wasm. That’s all I’m saying. I don’t think I understand what you mean in this reply.
      - austincheney 8y ago
        So currently there is demand for a DOM interface in WASM and WASM has none. I have seen several WASM applications that ship markup and then fabricate their own DOM-like instance to accompany that markup to allow web-like behaviors to the WASM application instance. That is a significant amount of overhead. If WASM had access to a DOM interface applications could be written in any language that execute DOM methods on accompanying markup without need for JavaScript. You get the benefits of a self-contained event-driven UI environment with minimal overhead and without need for JavaScript, but just because WASM ships with support for DOM method execution does not necessarily mean that execution reflects a state or environment outside the WASM sandbox.
        steveklabnik 8y ago
        Yeah, that does sound like a lot of overhead. > just because... It certainly will though, 100%. I know this from talking to all sorts of people who work on wasm. That’s what the above proposal I linked you to does.

by yarg 8y ago

austincheney 8y ago

MDN has a page for that as well: https://developer.mozilla.org/kab/docs/Web/API https://developer.mozilla.org/kab/docs/Web/API The page DOM is not listed there. The closet thing is DOMParser which will allow parsing of an XML/HTML island into a new DOM object. https://developer.mozilla.org/kab/docs/Web/API/DOMParser https://developer.mozilla.org/kab/docs/Web/API/DOMParser

steveklabnik 8y ago
What you're missing is https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md https://github.com/WebAssembly/host-bindings/blob/master/pro...
- austincheney 8y ago
  I believe you are over thinking this bullet point: > Ergonomics - Allow WebAssembly modules to create, pass around, call, and manipulate JavaScript + DOM objects That would allow WASM functionality similar to behavior already present in the browser, but that page does not say where that behavior will occur. Given this is an update to WASM it will likely occur against WASM artifacts. An example would be allowing a WASM application instance to create JavaScript event bindings and DOM artifacts on an internal DOM tree. It is wishful thinking that an update to WASM would modify the web environment outside of WASM.
  - steveklabnik 8y ago
    I think I’m just really confused as to what you’re saying. In the browser, you will be able to manipulate the browser DOM directly from wasm. That’s all I’m saying. I don’t think I understand what you mean in this reply.
    - austincheney 8y ago
      So currently there is demand for a DOM interface in WASM and WASM has none. I have seen several WASM applications that ship markup and then fabricate their own DOM-like instance to accompany that markup to allow web-like behaviors to the WASM application instance. That is a significant amount of overhead. If WASM had access to a DOM interface applications could be written in any language that execute DOM methods on accompanying markup without need for JavaScript. You get the benefits of a self-contained event-driven UI environment with minimal overhead and without need for JavaScript, but just because WASM ships with support for DOM method execution does not necessarily mean that execution reflects a state or environment outside the WASM sandbox.
      - steveklabnik 8y ago
        Yeah, that does sound like a lot of overhead. > just because... It certainly will though, 100%. I know this from talking to all sorts of people who work on wasm. That’s what the above proposal I linked you to does.