As a _user_ JSPI looks neat, however as a compiler writer JSPI looks like an horrible hairball of security issues and performance gotchas to degrade generated WASM code performance.

Say you have a WASM module, straight line code that builds a stack, runs quickly because apart from overflow checks it can just truck on.

Now add this JS-Promise thing into the mix:

A: now how does a JS module handle the call into the Wasm module? classic WASM was a synchronous call, now should we change the signature of all wasm functions to async?

B: does the WASM internal calls magically become Promises and awaits (Gonna take a lot of performance out of WASM modules), if not we now have a 2 color function world that needs reconciliation.

C: If we do some magic, where the full frame is paused and stored away, what happens if another JS function then calls into the WASM module and awaits and then the first one resumes? Any stack inside the wasm-memory has now potential race conditions (and potentially security implications). Sure we could make locks on all Wasm entries but that could cause other unintended side-effects.

D: Even if all of the above are solved, there's still the low-level issues of lowlevel stack management for wasm compiled code.

Looking at the mess that is emscripten's current solution to this, I really hope that this proposal gets very well thought out and not just railroaded in because V8's compiler manages to support it because.

1: It has the potential to affect performance for all Wasm code just because people writing Qemu,etc are too lazy to properly abstract resource loading to cooperate with the Wasm model.

2: It can become a burden on the currently thriving Wasm ecosystem with multiple implementations (honestly, stuff like Wasm-GC is less disruptive even if it includes a GC).

Regarding C - yes, multiple stacks should be supported, and I literally opened a PR to add coroutine support based on JSPI to emscripten: https://github.com/emscripten-core/emscripten/pull/25111

JSPI-based coroutines are much faster than the old Asyncify ones (my demo shows that).

As for your core message - I'm just the user, but if Google engineers were able to implement that, then it is possible to implement that securely. I remember Google engineers arguing with Apple engineers in GH issues, but I'm not on that level, I just see that JSPI is already implemented in Chrome, so you can't tell me it's not possible.

Multiple memories and Memory64 just became part of the spec. And JSPI is still being standardized. Is Safari slower to roll out new things? Yes. But it's hardly stopping adoption. Chrome has 70% of the browser market, Safari barely has 15%.

But Apple doesn't allow using other browser engines on iOS, so this matters much more. I mean, they were forced to allow them, but of course they didn't actually comply, they created artificial barriers to ensure only Safari can be used on iOS.

EDIT: By "safari" here I actually mean WebKit.

For the mobile browser market, Chrome is still around 70%, Safari is a bit better off in mobile at 20% of global browser market share. That's still a minority platform. It's not inhibiting wasm feature adoption with those numbers.