3 ms·

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

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.

themihai 9y ago
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).
IshKebab 9y ago
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.
- austincheney 9y ago
  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.
  - IshKebab 9y ago
    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/ http://webassembly.org/docs/high-level-goals/ > access browser functionality through the same Web APIs that are accessible to JavaScript
    - Nekorosu 9y ago
      > Otherwise how could it do anything at all?? By passing data.
- ridiculous_fish 9y ago
  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.
  - rickycook 9y ago
    plenty of typed languages have reflection. i don’t see how this changes anything?
    - ridiculous_fish 9y ago
      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.
      - steveklabnik 9y ago
        > WASM is not a typed language. It is a language-agnostic compilation target. These two things aren't contradictory. wasm is typed.
pjmlp 9y ago
Now imagine web sites written 100% in WASM, just like they were 100% in Flash. What did you won with Flash being replaced?

themihai 9y ago

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

IshKebab 9y ago

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.

austincheney 9y ago
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.
- IshKebab 9y ago
  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/ http://webassembly.org/docs/high-level-goals/ > access browser functionality through the same Web APIs that are accessible to JavaScript
  - Nekorosu 9y ago
    > Otherwise how could it do anything at all?? By passing data.
ridiculous_fish 9y ago
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.
- rickycook 9y ago
  plenty of typed languages have reflection. i don’t see how this changes anything?
  - ridiculous_fish 9y ago
    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.
    - steveklabnik 9y ago
      > WASM is not a typed language. It is a language-agnostic compilation target. These two things aren't contradictory. wasm is typed.

pjmlp 9y ago

Now imagine web sites written 100% in WASM, just like they were 100% in Flash. What did you won with Flash being replaced?