New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

馃洡 ECMAScript module integration #1087

Open
jfbastien opened this Issue Jun 2, 2017 · 1 comment

Comments

Projects
None yet
3 participants
@jfbastien
Member

jfbastien commented Jun 2, 2017

This is a tracking issue for a post-MVP feature
It will be updated as the issue progresses.

Topic ECMAScript module integration
Champion Link Clark @linclark
Status Not started
Phase feature proposal
Linked issues #997 #972 #969 #657 #252 #119
Linked repositories esm-integration

Details

WebAssembly programs are currently represented through a WebAssembly.Module, which can be instantiated as WebAssembly.Instance. Both of these present themselves as regular JavaScript objects which don't interact with ECMAScript modules (both the static modules in ES6 as well as proposed dynamic module loading).

While ES6 defines how to parse, link and execute a module, ES6 does not define when this parsing/linking/execution occurs. An additional extension to the HTML spec is required to say when a script is parsed as a module instead of normal global code. This work is ongoing.

Currently, the following entry points for modules are being considered:

  • <script type="module">;
  • an overload to the Worker constructor;
  • an overload to the importScripts Worker API;

Additionally, an ES6 module can recursively import other modules via import statements.

For WebAssembly/ES6 module integration, the idea is that all the above module entry points could also load WebAssembly modules simply by passing the URL of a WebAssembly module. The distinction of whether the module was WebAssembly or ES6 code could be made by namespacing or by content sniffing the first bytes of the fetched resource (which, for WebAssembly, would be a non-ASCII鈥攁nd thus illegal as JavaScript鈥magic number).

Thus, the whole module-loading pipeline (resolving the name to a URL, fetching the URL, any other loader hooks) would be shared and only the final stage would fork into either the JavaScript parser or the WebAssembly decoder.

Any non-builtin imports from within a WebAssembly module would be treated as if they were import statements of an ES6 module. If an ES6 module imported a WebAssembly module, the WebAssembly module's exports would be linked as if they were the exports of an ES6 module. Once parsing and linking phases were complete, a WebAssembly module would have its start function, defined by the start module option, called in place of executing the ES6 module top-level script. By default, multiple loads of the same module URL (in the same realm) reuse the same instance. It may be worthwhile in the future to consider extensions to allow applications to load/compile/link a module once and instantiate multiple times (each with a separate linear memory).

This integration strategy should allow WebAssembly modules to be fairly interchangeable with ES6 modules (ignoring GC/Web API 馃 future feature signature restrictions of the WebAssembly MVP) and thus it should be natural to compose a single application from both kinds of code. This goal motivates the semantic design of giving each WebAssembly module its own disjoint linear memory. Otherwise, if all modules shared a single linear memory (all modules with the same realm? origin? window?鈥攅ven the scope of "all" is a nuanced question), a single app using multiple independent libraries would have to hope that all the WebAssembly modules transitively used by those libraries "played well" together (e.g., explicitly shared malloc and coordinated global address ranges). Instead, the dynamic linking future feature is intended to allow explicitly sharing state between module instances.

jfbastien added a commit that referenced this issue Jun 2, 2017

Remove ES6 module integration
Now tracked by: #1087
As discussed here: #1066

@jfbastien jfbastien changed the title from ECMAScript module integration to 馃洡 ECMAScript module integration Jun 2, 2017

@WebAssembly WebAssembly locked and limited conversation to collaborators Jun 2, 2017

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jun 2, 2017

Member

I'm interested in helping with this, although perhaps not quite championing.

For WebAssembly/ES6 module integration, the idea is that all the above module entry points could also load WebAssembly modules simply by passing the URL of a WebAssembly module. The distinction of whether the module was WebAssembly or ES6 code could be made by namespacing or by content sniffing the first bytes of the fetched resource (which, for WebAssembly, would be a non-ASCII鈥攁nd thus illegal as JavaScript鈥攎agic number).

It should be made by content-type determination.

Member

domenic commented Jun 2, 2017

I'm interested in helping with this, although perhaps not quite championing.

For WebAssembly/ES6 module integration, the idea is that all the above module entry points could also load WebAssembly modules simply by passing the URL of a WebAssembly module. The distinction of whether the module was WebAssembly or ES6 code could be made by namespacing or by content sniffing the first bytes of the fetched resource (which, for WebAssembly, would be a non-ASCII鈥攁nd thus illegal as JavaScript鈥攎agic number).

It should be made by content-type determination.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.