There is clearly some sort of mapping available to a JavaScript FFI for doing I/O, as both the Unreal engine and Unity have been ported to WebAssembly. If you can run a video game engine in the browser you can run anything. I believe there are proposals in place as well to add opcodes to directly interface with browser capabilities rather than going through a JS FFI.
- processing data from LHC collisions or imaging satellites.
- etc
- etc
- etc
just because webgl enables fast gpu processing (by basically writing a small subset of C that is shader code) doesnt now mean the web platform can be used for evetything.
You can emulate a network stack and hardware drivers, but your "network stack" can't directly send packets outside of HTTP/Websockets/WebRTC/etc. and your "hardware drivers" just emulate hardware that doesn't actually exist.
Trading algorithms, ultra low latency DSP, "processing data from LHC collisions or imaging satellites" are I think references to performance limitations. WebAssembly requires a fair bit of runtime checks (though some can be pawned off to the hardware if you're clever), and has a number of other quirks that hurt performance, like the fact that most languages end up needing two stacks when compiled for wasm.
The issue is even clearer when you move to processing large data sets because WebAssembly only allows a 32-bit address space at the moment. Add to that the lack of concurrency or native SIMD, and it's pretty clear it is way too early to dance on the graves of native executables.
Runtime checks don't stop you from doing heavy data processing or having microsecond-level response times. It seems like your objections fall into two categories. One is caused by it running in ring 3, which can be solved by correcting "anything" to "any user program". The other is moderate performance limitations that don't stop it from running full video game engines. Those may not be ideal but they won't stop you from running anything. Video games are among the most demanding things you can do in most ways. The single core of today is better than the multi core of a few years ago, and nobody claimed that those couldn't run all programs.
The memory limits will definitely completely prevent you from running some real-world programs. Programs that don't fold well into a single threaded event loop are also a problem at the moment (including Unreal/Unity games that use background threads).
Also, unless you definition of "can run a game" includes "can run a game at 3fps" I'm pretty skeptical that the entire repitoire of games for those engines can make the jump to WebAssembly today.
wish i had more time for the multitude of your generic "why not?"s, but i don't :(
any language (high or low level) that allows you to write and execute deterministic assembly or machine code can be used to implement whatever you want. whether WASM ever reaches this type of broad security-sensitive wild-west remains to be seen, but my money is on "never".
wasm will certainly expand into additional areas, but they will all be security-gated and will not have unfettered, raw access to all hardware (even with some additional user-grokkable permission model), because it has to run on the web: "W"asm
