The most important reason is that Javascript can focus on being a programming language again, not a compile target, and WASM can focus on being an efficient compile target, but doesn't need to be a language. The WASM spec can be extended independently from the Javascript spec, this enables faster introduction of new features (and the process is actually working!).
WASM is especially important to close the performance- and power-efficiency gap that exists on mobile between native applications and Javascript applications. Writing a JS app that doesn't use garbage collection, and doesn't get re-jitted while running isn't trivial, in WASM this is guaranteed. Only the initial parsing is burning a few more CPU cycles compared to a native application, from then on, the difference is small or non-existent.
In the end, WASM is also an important counter-force to the closed ecosystems on Android and iOS. It is the key to have a system that's both open and reasonably secure.
I am not concerned about the view source aspect, but this is actually an important topic to the WASM designers. Browsers have a "view source" on WebAssembly, which shows the ASCII representation, and this is surprisingly readable, since WASM is a higher level representation than traditional CPU assembly (the name WebAssembly is a really poor choice IMHO).
In the end, shipping the high level source code to client devices, and compiling the code there is a massive waste of resources, it's better if this only happens once on the developer machine. The "open source aspect" needs to come from the developer by hosting the original source code on e.g. github, but even if developers want to keep their code closed, the WebAssembly view-source provides enough info to reverse-engineer their code, and with time, better disassembly tools will be created which can recreate a "highlevel representation", stuff like this also exists for traditional executables.
WASM is especially important to close the performance- and power-efficiency gap that exists on mobile between native applications and Javascript applications. Writing a JS app that doesn't use garbage collection, and doesn't get re-jitted while running isn't trivial, in WASM this is guaranteed. Only the initial parsing is burning a few more CPU cycles compared to a native application, from then on, the difference is small or non-existent.
In the end, WASM is also an important counter-force to the closed ecosystems on Android and iOS. It is the key to have a system that's both open and reasonably secure.
I am not concerned about the view source aspect, but this is actually an important topic to the WASM designers. Browsers have a "view source" on WebAssembly, which shows the ASCII representation, and this is surprisingly readable, since WASM is a higher level representation than traditional CPU assembly (the name WebAssembly is a really poor choice IMHO).
In the end, shipping the high level source code to client devices, and compiling the code there is a massive waste of resources, it's better if this only happens once on the developer machine. The "open source aspect" needs to come from the developer by hosting the original source code on e.g. github, but even if developers want to keep their code closed, the WebAssembly view-source provides enough info to reverse-engineer their code, and with time, better disassembly tools will be created which can recreate a "highlevel representation", stuff like this also exists for traditional executables.