12 ms·

> if people can ship WASM to the browser to do what they’re currently doing with JS If if if.... That is not what WASM is or whats to be. > I’ve long maintain

> if people can ship WASM to the browser to do what they’re currently doing with JS If if if.... That is not what WASM is or whats to be. > I’ve long maintained that the reason that JS is so prelevant and popular is the result of it exclusively being the only language allowed in the browser. People who hate JavaScript have long maintained that, without evidence. I can remember writing JavaScript long before it became popular and was still everywhere. > WASM API comes along (and it will), JS will be as good as deprecated. A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure.

FridgeSeal 8y ago
> A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure. More insecure than allowing arbitrary JS like we do now? I wouldn’t be surprised if we do get a WASM DOM API, maybe it won’t start as an official spec, but it’ll eventually happen.
- afiori 8y ago
  a DOM API for wasm is planned, but IIRC before that people need to standardize the whole concept of external references/GC, so it might be still quite far away.
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.

FridgeSeal 8y ago

> A DOM interop spec is underway, which will allow access into the WASM target from JavaScript. It will not allow access from WASM to the DOM, because that is insecure. More insecure than allowing arbitrary JS like we do now? I wouldn’t be surprised if we do get a WASM DOM API, maybe it won’t start as an official spec, but it’ll eventually happen.

afiori 8y ago
a DOM API for wasm is planned, but IIRC before that people need to standardize the whole concept of external references/GC, so it might be still quite far away.

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.