Intent to experiment - Wasm JavaScript Promise Integration

[Francis McCabe]

Contact emails

f...@chromium.org

Explainer

https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md

Specification

https://github.com/WebAssembly/js-promise-integration/blob/main/proposals/js-promise-integration/Overview.md

Summary

Stack Switching denotes a technology that allows programs to suspend and resume computation. This is an active area that is part of the WebAssembly standards track. See https://github.com/WebAssembly/stack-switching and https://github.com/WebAssembly/meetings/tree/main/stack. This particular feature refers to the integration between JavaScript Promises and stack switching. This is described in more detail in https://docs.google.com/document/d/16Us-pyte2-9DECJDfGm5tnUpfngJJOc8jbj54HMqE9Y/edit#

Blink component

Blink>JavaScript>WebAssembly

Search tags

stack switching, Promise, JSPI

TAG review

TAG review status

Pending

Risks

Interoperability and Compatibility

This spec is backed by a standardization effort. We do not plan to ship the JSPI until it has been standardized by the W3C Wasm WG. However, post standardization, we will depend on all browsers implementing the standard.

Gecko: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=1850627) Mozilla have started their own imlementation

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

Goals for experimentation

Ongoing technical constraints

None.

Debuggability

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

No

Flag name on chrome://flags

Finch feature name

None

Non-finch justification

None

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/v8/issues/detail?id=12191&q=owner%3Ame&can=2

Estimated milestones

OriginTrial desktop last	130
OriginTrial desktop first	122

OriginTrial Android last	130
OriginTrial Android first	122

OriginTrial webView last	130
OriginTrial webView first	122

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5674874568704000

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAdKk6BGFseZ6pBO2qEW_xeovVw1_guVq26rcNM1nWY442Y5Ng%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Rick Byers]

Hi Francis,

This seems good to experiment with to me. But the key question is who is actually going to test it out in production? You mention "no signals" for web developer interest. There's not much point in doing the overhead of an OT unless we have at least one developer who wants to test out the functionality in a production environment. Can you elaborate?

Thanks,

   Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE65UWD8e57Bd5x3nr63M3QcdPo6TKom%2BVZT%3DvO2Uo4x6th_kA%40mail.gmail.com.

[Francis McCabe]

In fact, there are several potential partners for evaluating/experimenting with JSPI: the Google Earth team, Figma, Adobe to name a few. It should be emphasized that there are no formal agreements in place here; and that the primary use case for these partners is actually dynamic loading of code (and other) resources on the main thread.

[Ken Russell]

Google's Meet team also desires to use JSPI to simulate synchronous GPU->CPU readbacks in C++ code on top of the web's asynchronous primitives.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3b3e2a05-2375-4b68-a2d4-57230e192e62n%40chromium.org.