Intent to Ship: WebAssembly JS String Builtins

[Adam Klein]

Contact emails

ecmzi...@chromium.org, jkum...@chromium.org, ad...@chromium.org

Explainer

https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md

Specification

https://webassembly.github.io/js-string-builtins/js-api/

Summary

This feature exposes common JS string operations for easy import into WebAssembly and optimizations thereof. This allows creating and manipulating JS strings from WebAssembly without native support within WebAssembly while still allowing for a similar performance as native string references. The mechanism works by exposing suitably strict versions of JS string operations in the WebAssembly JS API. These can be imported by modules using externref as a generic data type for storing the strings. The engine can identify that these imports can be represented by native graph operators without the need for calling into JS. This leads to a comparable peak performance as native string operations while allowing quick interoperability with JS since no copying at the boundary is required when calling into arbitrary JS functions that consume strings.

Blink component

Blink>JavaScript>WebAssembly

TAG review

https://github.com/w3ctag/design-reviews/issues/940

TAG review status

Completed (with "Resolution: satisfied")

Chromium Trial Name

WebAssemblyJSStringBuiltins

Link to origin trial feedback summary

https://docs.google.com/document/d/1zL9goDsawTQUFuuQ8ddI_pUcLY1_iFOsHaDZ374dnGw/edit?usp=sharing

Origin Trial documentation link

https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md

Risks

Interoperability and Compatibility

This proposal is at Phase 4 in the WebAssembly spec process

Gecko: Positive

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/343)

Web developers: Positive (see OT feedback)

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?

None

Debuggability

None

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

Yes

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

Yes

Flag name on chrome://flags

None

Finch feature name

WebAssemblyJSStringBuiltins

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop	130
Origin trial desktop first	119
Origin trial desktop last	127
Origin trial extension 1 end milestone	130
Shipping on Android	130
Shipping on WebView	130

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6695587390423040?gate=6542541230440448

Links to previous Intent discussions

Intent to Experiment: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPAU7RyzxKa0Pj6q7B_jyfT%3DH%2BSK264%3Dx8wn1ans%3D8UjHRhctQ%40mail.gmail.com
Intent to Extend Experiment 1: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_16woqtqCWOW7Gr4uy2iX3hvj3iSYXQWZaVOc9q9e1Nw%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Chris Harrelson]

Is there a standards position issue tracking this?

 

--
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/CAEvLGc%2BP1ZN9pOGTR_83vqT7JbQVyyoZ-At5qK0sv_f0FVxnJg%40mail.gmail.com.

[Adam Klein]

I don't believe so. The proposal is championed by Ryan Hunt of Mozilla, who works on WebAssembly in SpiderMonkey. In order to reach Phase 4, the proposal needed two web engine implementations, and Firefox nightly has support for it, alongside Chrome.

[Chris Harrelson]

Thanks!

LGTM1

[一丝]

Firefox has been implemented and is waiting to be shipped.

https://bugzilla.mozilla.org/show_bug.cgi?id=1876148

[Domenic Denicola]

LGTM2.

Do we have a sense of WebKit's view of the proposal, e.g. through WebKit participation in the Wasm CG?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/26fc12ff-7795-4fca-9153-d286afadc68cn%40chromium.org.

[Yoav Weiss (@Shopify)]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra_Az8KrP7vq81gsc_wZvFEUU9sQBJUxEmYH9soquP6d3A%40mail.gmail.com.

[Adam Klein]

On Tue, Sep 3, 2024 at 8:17 PM Domenic Denicola <dom...@chromium.org> wrote:

LGTM2.

Do we have a sense of WebKit's view of the proposal, e.g. through WebKit participation in the Wasm CG?

WebKit reps at the CG haven't objected to phase advancements of the proposal, and thus are in line with the group's consensus that JS String Builtins become a standard part of the Wasm/JS API. But I don't recall them saying much on the record about this proposal (which is why I filed the standards issue, despite that not being a step we usually take for Wasm features).