WASM is like Java bytecode without access to the Java standard library (like, no `java.lang.String` or even `java.lang.Object`... just the primitives).
But it has a mechanism to call "host" or "imported" functions and to use linear memory (an array of bytes which can be shared with other modules and the host), which is how it actually does anything useful.
I can imagine a version of Java that works like this as well, actually, I wonder if there's ever been anything like that?
"Once".
That GC proposal isn't anywhere close to landing. It's making progress, but it's the "Zeno's paradox" kind of progress where the feature seems further away the more they work on it. I wouldn't be surprised at all if it still wasn't supported in browsers in 10 years.
"USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly"
https://www.youtube.com/watch?v=glL__xjviro
Then there are the issues that since WebAssembly doesn't prevent memory corruption, while RCE attacks or sandboxing breaks are not possible, by producing memory corruption, it is possible to eventually trigger alternative code paths that wouldn't be possible in normal circumstances.
A contrived use case would be to validate a user with higher credentials that they are supposed to have, in a WASM based security module.
Then since the external calls from the module are configured from the runtime, one can do man on the middle attacks on the functions being called from the module, thus access data that it wasn't supposed to be made available in normal cases.
And I bet that when the hacker community starts having fun with WebAssembly, as much as they have had with other bytecode formats, more issues will be found.
It's less of a problem in 2021 than it was in 1995.
Ironically, those boycotts are now meaningless given Chrome market share, including Electron.