Document what Web Assembly imposes on the web platform

[jfbastien]

Before going public we should understand what we're imposing on embedders, especially the web platform. Key questions to answer:

1. How, if at all, is the web platform changing to support Web Assembly?
2. What code changes are we imposing on browser implementations?

Theoretical examples:

• An app which uses HTML+JS+WASM could relinquish WebGL-from-JS-main-thread-only, and move the WebGL control to a wasm thread instead.
• Can a wasm app block the JS main thread?

Web Assembly will also drive / justify new features into the web platform, such as SharedArrayBuffer, SIMD.js, imporved filesystem support, improved networking support, ... It's not just imposing itself onto the web platform!

[jfbastien]

Web Assembly will eventually (not V1) support GC. Some GC will be internal to the Web Assembly application, but some may be shared with the embedder. This later type of work is similar to Chrome's Oilpan project, and is quite complicated for the embedder.

[sunfishcode]

WebAssembly is meant to become an integrated part of the Web platform, rather than always being an imposition, so long term, maintaining a list of things it's "imposing" on the platform isn't where we want to focus, in my opinion. But short term, it's important to understand how WebAssembly will initially fit in. I think we can say wasm is starting with:

• Can you move WebGL control from JS to wasm on the same thread (once wasm supports calling WebGL directly)? Yes, it seems like this ought to work; see Fill in a more detailed sketch for GC/DOM/Web API integration #275.
• Can you move WebGL control from one thread to another? I think that's a question for the WebGL API, and not something we can address through WebAssembly itself.
• Can a wasm app block the JS main thread? I believe the answer is yes, we'll have synchronous calls into wasm from JS (unless Does WASM share a stack with JS? #126 changes that). This isn't fundamentally different from the main thread calling into a JS library that does a bunch of computation, effectively blocking the main thread.

Is there anything else that needs answering here at this time?

[kenchris]

I guess that existing API might also need some kind of integration. Like I can imaging that people want to use WASM for optimizing sound processing, so maybe some integration with WebAudio would be needed to make this easier. I guess the same for HTML5 audio/video, filters.

Now we are getting Service Workers, so I expect that WASM will enable new use-cases as transcoding files in software, so it would also be good to understand if anything special is needed for that.

[sunfishcode]

#275 is working on the first steps. Beyond that, taking advantage of WebAssembly and Service Workers is largely up to individual APIs. I agree that there are some interesting possibilities opening up.

[sunfishcode]

If there are further questions, please open a new issue.