Indeed, I/O APIs (anything that talks to the outside world) are another sore point for WebAssembly, as browsers do not currently expose any particular APIs dire

Indeed, I/O APIs (anything that talks to the outside world) are another sore point for WebAssembly, as browsers do not currently expose any particular APIs directly to Wasm, only to JavaScript. So Wasm has to make calls to a JavaScript middleman layer to use those APIs. But browsers are understandably hesitant to create a whole parallel API surface designed specifically for Wasm callers. That's a lot of work. I am not totally convinced that this is a real problem, vs. just something that makes people feel bad. Like, if you are coding Rust, the idea that all your "system calls" are calling into a layer of JavaScript feels disgusting. But is it a real problem? Most of these calls are probably not so performance sensitive that this FFI layer matters that much. If it is a real problem, I'd guess the answer is for browsers to come up with a more efficient way to expose WebIDL-defined APIs to Wasm, but without reinventing any individual APIs. Being derived from WebIDL, they are still going to have JS idioms in their design, but maybe we can at least skip invoking actual JavaScript.