Skip to content
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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] WebAssembly JavaScript Module integration #4372

Closed
wants to merge 1 commit into from

Conversation

littledan
Copy link
Contributor

@littledan littledan commented Feb 16, 2019

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

<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx/1.10.3</center>
</body>
</html>

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.

@littledan
Copy link
Contributor Author

littledan commented Feb 16, 2019

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 annevk added addition/proposal New features or enhancements do not merge yet Pull request must not be merged per rationale in comment topic: script labels Feb 17, 2019
@littledan
Copy link
Contributor Author

For reference, see the (early draft) Wasm side: https://webassembly.github.io/esm-integration/js-api/index.html#esm-integration

Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

source Outdated Show resolved Hide resolved
source Outdated Show resolved Hide resolved
@littledan
Copy link
Contributor Author

Thanks for the review, @annevk ! I addressed those issues, with a related mimesniff PR at whatwg/mimesniff#95 .

source Outdated Show resolved Hide resolved
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. -->
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

@ExE-Boss
Copy link

Will this allow for:

<script type="application/wasm" src="./main.wasm"></script>

To import a top‑level WebAssembly module?


Refs: WebAssembly/esm-integration#38

@annevk
Copy link
Member

annevk commented Nov 30, 2020

I hope (and think) not, the type attribute of the script element should not take new MIME types. If we need to declare WebAssembly client-side for some reason it should be type=wasm or equivalent.

@annevk
Copy link
Member

annevk commented Apr 3, 2024

The discussion in WebAssembly/esm-integration#78 has made me wonder whether Wasm module scripts should have their own import attribute type.

@Ms2ger
Copy link
Member

Ms2ger commented Apr 4, 2024

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.

@annevk
Copy link
Member

annevk commented Jul 12, 2024

Let's dupe this into #10380.

@annevk annevk closed this Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements do not merge yet Pull request must not be merged per rationale in comment topic: script
Development

Successfully merging this pull request may close these issues.

4 participants