I disagree from a technical perspective. WASM is a box much like an iframe or a Java applet or Flash media. Therefore the things contained within that box are isolated from the things outside that box. JavaScript, on the other hand, operates outside that box and, with appropriate bindings, can interface with APIs inside that box.

The WASM will replace JavaScript argument exists not for any valid technology reasoning, because people desperately need it to (only for personal reasons) and don't understand how web technologies work on the front end.

The goal of WASM was never to replace JavaScript, but to replace Flash (before Adobe announced the death of Flash) in a language agnostic way.

I believe you are wrong. WASM has a text version and nothing stops you from using the DOM or the web APIs (given that wasm gets an API). What exactly is the black box? You can use OpenGL in javascript too if that's what you mean by "black box". You can't do anything new in wasm than in JS except you get better performance and more options (language wise).

Now imagine web sites written 100% in WASM, just like they were 100% in Flash.

What did you won with Flash being replaced?

Currently WASM can't access the DOM. But WASM-native DOM APIs are planned and then you will be able to completely ditch Javascript if you want.

Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started. As others have mentioned there is the hosting bindings API that is well underway, which provides web APIs to the WASM container so that code compiled to WASM can interact with the JavaScript outside it. This doesn't sound like what you are hoping for though.

At this time, and for the foreseeable future, there are no plans with active code in development to implement WASM as a JavaScript replacement, at least to my knowledge.

Code compiled to WASM can already access Javascript outside it. Obviously. Otherwise how could it do anything at all??

> Issues have been opened for native DOM bindings in WASM, but I am not sure if that work ever started.

I didn't say work had started on it. I just said that it is planned. See here for proof: http://webassembly.org/docs/high-level-goals/

> access browser functionality through the same Web APIs that are accessible to JavaScript

> Otherwise how could it do anything at all??

By passing data.

Can you speculate on what these APIs will look like? JS is well suited for dealing with cross-browser incompatibilities because of its reflection support. That is much harder to build in a low-level target like WASM. COM is an example of what we might get, and that is not a pleasant prospect.

plenty of typed languages have reflection. i don’t see how this changes anything?

WASM is not a typed language. It is a language-agnostic compilation target.

So what would a DOM API exposed to WASM look like? COM is the only example that comes to mind.

> WASM is not a typed language. It is a language-agnostic compilation target.

These two things aren't contradictory. wasm is typed.