[spankalee]

I'll be very happy when Preview 3 with async support is out.

GC + async makes WASM a suitable runtime for languages like JavaScript and Dart so that we don't have to have JS + WASM runtimes where the JS doesn't integrate with WASI well, or WASI runtimes that don't support JS that well (compiling SpiderMonkey to WASM isn't great).

[phickey]

We have already made big improvements in using SpiderMonkey on WASM, and have more work in progress that will enable SpiderMonkey to have "native"-like codegen for WASM: https://cfallin.org/blog/2023/10/11/spidermonkey-pbl/

An additional benefit of using a fast JS runtime inside of WASM, even on a WASM engine that natively supports JS, is to use a Wasm Component as a security boundary around JS code. This could be used as an means of isolating supply-chain security issues, or allowing users to provide (untrusted) JS code that extends an existing system while having a clear and strong boundary on how untrusted JS code can affect the host JS code.