WebAssembly JS String Builtins

concepts

1. JS String Builtins probe

   Capability probe + inspection of the imported builtin names a wasm module can request (wasm:js-string/length, wasm:js-string/concat, etc.).

2. Performance benchmark

   The motivation by name: "similar performance as native string references". Live benchmark contrasts the legacy UTF-8 marshalling round-trip with the direct-externref builtins path, on length, charCodeAt, substring, and concat — with measured speed-up.

3. Import binding playground

   Reference card for all ten standardised builtins (length, charCodeAt, fromCharCode, codePointAt, concat, substring, equals, compare, intoCharCodeArray, fromCharCodeArray). Each one emits the exact JS imports object, the matching WAT (import "wasm:js-string" …) line, a step-by-step trace, and a live result for sample inputs you can edit.

4. String Ops Bench

   Benchmark six string operations (concat, charCodeAt, substring, length, indexOf, comparison) at configurable iteration counts and string lengths. Shows relative throughput — the baseline for what JS String Builtins eliminate at the Wasm↔JS boundary.

why it shipped

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 str

references

• ChromeStatus entry
• Spec