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