Yeah, and like many engineering marvels, it was instantly misused for purposes its creators didn't intend and became a scourge on humanity (looking at you NodeJS & co).

And WASM hasn't been around for as long, so WASM implementations are not as mature.

There is no reason why WASM couldn't be as fast, or faster than JS, especially now with WASM 3.0. Before, every programs in a managed language had to be shipped with its own GC and exception handling framework in WASM which was probably crippled by size constraints.

They still need to, because WASM GC is a MVP that only covers a subset.

Any language with advanced GC algorithms, or interior pointers, will run poorly with current WASM GC.

It works as long as their GC model overlaps with JS GC requirements.

It's also currently only a subset of JS GC requirements at that. It's the bare minimum to share references between JS and WASM to byte arrays like Int32Array. It's like basic OS-level memory page sharing only for now.

Some of the real GC tests will be strings support (because immutability/interning) and higher-level composite objects, which is all still in various draft/proposal states.

Oh, even worse than I thought.