Feature detection and running Web Assembly

[jfbastien]

The initial polyfill will unconditionally load JavaScript code, then load the Web Assembly binary blob, and somehow translate it to a form that'll execute using the JavaScript VM.

Once we have native support this polyfill will be a fallback: developer's code should only load the polyfill and use it if Web Assembly isn't natively supported.

How will we detect native Web Assembly support? Something like navigator.mimeTypes['application/x-wasm'] !== undefined?

How will we trigger the browser's native support? Use an <embed> or <script> tag?

[kg]

We also need to solve the problem of having a native web assembly decoder that isn't new enough to run the application. In that scenario we want to fall-back as soon as possible - either to a polyfill with the new feature(s), or to an alternate fall-back wasm executable. If we do this wrong, we end up with applications that just silently fail or with dramatically compromised load times from doing the load/startup work twice.

[kg]

<script> might be a poor choice for this. There are some things to consider about how it would interact with wasm:

What will async and defer do? Nothing? The whatwg spec for those two attributes uses language like 'will'. Is it possible to implement these behaviors consistently with a polyfill?

What will the crossorigin attribute do? How does cross-origin interact with this in general, since a wasm executable probably contains non-code resources that will be accessible from code? Can we implement this using a polyfill (CORS xhr, I guess)?

What happens if it's <script> with a body instead of a src attribute? Do we make that illegal?

How does the wasm <script> fallback work given that it needs to be (potentially) synchronous like it would be if it were 'text/javascript'?

[jfbastien]

CORS is a great question! We had a slightly related discussion in #53 w.r.t. dynamic linking. Let's make sure security folks are involved in this issue too.

[BrendanEich]

Suggest not abusing embed, which is subject to filtering and which has historical baggage about being a rectangular hole in your page for plugins. Similar thinking goes against object, if I'm not mistaken.

Raced @kg's comment. I was going to argue for script, not because it's perfect (nothing is), but because it is close by construction (based on the polyfill). In particular the security mechanism and policy should not diverge without good reason. I think this takes in CORS, CSP, etc.

We could add a new element that does not have a body. Adding anything with an implicit-CDATA body such as script has (which I got away with once, in 1995) is considered bad by WHATWG gurus, based on hardship updating browsers and validators, and attendant security risks.

/be

[lukewagner]

When integrating with ES6 modules, it seems natural to load a wasm module the same way as an ES6 module: import from another module, URL passed to <script> or Worker, call to JS API, etc. Thus, the integration point for the wasm polyfill would be either (a) if ES6 modules were supported natively, the module loader pipeline (which is specifically intended to do things like this), or (b) if ES6 modules were not natively supported, the module loader polyfill.

For feature testing: independently we've discussed allowing both JS and WebAssembly to feature-test WebAssembly features (since the usual JS technique of testing for the existence of constructors on the global object won't be available). Inside WebAssembly code, that suggests some op that's given a string literal immediate (naming the feature) that statically evaluates to true/false. In JS code, that suggests some hasWebAssemblyFeature("feature") JS function. Thus, the existence of the hasWebAssemblyFeature function could be the test for WebAssembly itself.

[jfbastien]

WebAssembly will be an object in JS, so this is not relevant anymore.