Earlier quoted context omitted.
WASM replaces Javascript as the target of other language compilers. JavaScript is also a compile target in a sandbox. Emscripten started with outputting plain JS, then that was optimized to asm.js, now optimized to WASM. I completely agree that WASM should NOT replace JS for normal DOM apps. It's currently possible through awkward calls into JS, and might be possible in the future more directly, but there's no need t…
> WASM replaces Javascript as the target of other language compilers. No, it does not. Compiling to WASM is not a replacement or synonym for compiling to JavaScript. JavaScript is not locked in a sandbox, in the same way, as it has a multitude of APIs. WASM does not have such APIs as it is just the sandbox. Here is the deal. All modern browsers now claim to support WASM. If WASM were capable of replacing JavaScript i…
WASM can CALL INTO JAVASCRIPT CODE. Which means it can do anything JS can do — in a "clunky hack" kind of way, sure, but people are building sugar on top of this already: https://github.com/koute/stdweb
So it's not the kind of sandbox you're thinking about. It's literally the same sandbox as JavaScript itself.
Also, I just realized — you're probably thinking of "compiling to JS" as in TypeScript/BuckleScript/Elm/ghcjs/ScalaJS/… — and yeah, that isn't easy to replace, because you'd have to implement a whole garbage collected runtime for WASM currently and that's kinda ridiculous.
Others (including me) are thinking of "compiling" as in Emscripten, and WASM was literally created to optimize this at first.