[WIP] WebAssembly JavaScript Module integration #4372
Conversation
|
Phrasing this as PR, although it's not yet ready to seek implementer buy-in, at @annevk's suggestion. I hope this will be a good way to get further feedback on the Wasm/ESM integration proposal. |
annevk
added
addition/proposal
|
For reference, see the (early draft) Wasm side: https://webassembly.github.io/esm-integration/js-api/index.html#esm-integration |
Intended to improve precision in: - https://webassembly.github.io/spec/web-api/index.html#compile-a-potential-webassembly-response - whatwg/html#4372
Intended to improve precision in: - https://webassembly.github.io/spec/web-api/index.html#compile-a-potential-webassembly-response - whatwg/html#4372
littledan
force-pushed
the
wasm-js-modules
branch
from
df1b1ba
to
bdae4df
Compare
|
Thanks for the review, @annevk ! I addressed those issues, with a related mimesniff PR at whatwg/mimesniff#95 . |
littledan
force-pushed
the
wasm-js-modules
branch
from
bdae4df
to
d7f9e27
Compare
For concreteness, this patch specifies how the WebAssembly JavaScript module integration proposal [1] could work in HTML. It is not yet ready to merge, as the proposal is still in a relatively early state. Note that this change depends on the ability for modules to block in the evaluation phase, to permit WebAssembly module instantiation to yield, as is necessary on some platforms where compilation work is performed during the first instantiation. Such an ability to yield is provided by the JavaScript top-level await proposal [2] and associated HTML integration patch whatwg#4352. [1] https://github.com/webassembly/esm-integration [2] https://github.com/tc39/proposal-top-level-await
| <var>settings</var>'s <span>responsible browsing context</span>, then set | ||
| <var>bufferPromise</var> to a promise resolved with an empty | ||
| <code data-x="idl-ArrayBuffer">ArrayBuffer</code>.</p></li> | ||
| <!-- REVIEW NOTE: this will cause a parse error, because it doesn't have the magic bytes. --> |
There was a problem hiding this comment.
I'm not quite sure how to handle this; is this even the right place for this check? Should JSON/CSS modules have this check as well?
There was a problem hiding this comment.
This seems like a generically good idea by analogy, but it's hard for me to figure out how this check is reachable. Don't the various 'entry points' to this specification path already check if scripting is disabled?
|
Will this allow for: <script type="application/wasm" src="./main.wasm"></script>To import a top‑level WebAssembly module? |
|
I hope (and think) not, the |
|
The discussion in WebAssembly/esm-integration#78 has made me wonder whether Wasm module scripts should have their own import attribute type. |
|
I haven't been able to follow the recent discussion, but my understanding is that transparently swapping out a js library for a wasm re-implementation was a goal. Other requirements might outweigh that, though. |
|
Let's dupe this into #10380. |
For concreteness, this patch specifies how the WebAssembly JavaScript
module integration proposal [1] could work in HTML. It is not yet ready
to merge, as the proposal is still in a relatively early state.
Note that this change depends on the ability for modules to block in the
evaluation phase, to permit WebAssembly module instantiation to yield,
as is necessary on some platforms where compilation work is performed
during the first instantiation. Such an ability to yield is provided by
the JavaScript top-level await proposal [2] and associated HTML
integration patch #4352.
[1] https://github.com/webassembly/esm-integration
[2] https://github.com/tc39/proposal-top-level-await
💥 Error: Wattsi server error 💥
PR Preview failed to build. (Last tried on Jan 15, 2021, 7:59 AM UTC).
More
PR Preview relies on a number of web services to run. There seems to be an issue with the following one:
🚨 Wattsi Server - Wattsi Server is the web service used to build the WHATWG HTML spec.
🔗 Related URL
If you don't have enough information above to solve the error by yourself (or to understand to which web service the error is related to, if any), please file an issue.