That's true, but to get any sort of 'near-native' performance out of that approach, browsers had to add special support for asm.js, running asm.js as regular Javascript would loose 3..10x performance compared to 'special cased' asm.js (if I remember right - for instance iOS Safari never added this special asm.js support, and once it supported WASM the performance jump from asm.js to WASM was dramatic and much bigger than desktop browsers which already had added special asm.js support before).
Compared to an asm.js special case in a Javascript engine, the WASM approach just makes a lot more sense, because Javascript can now focus again on being a programming language and not also being a good compile target.
Also, WASM does expose things that (afaik) aren't available in JS, like int64, SIMD, atomics, etc.
It's used to compile your app in a format that can run on any machine with a web browser.
https://floooh.github.io/tiny8bit/
Also see: https://github.com/floooh/sokol and https://floooh.github.io/sokol-html5/index.html.
(e.g. for me it's a way to easily get my C/C++ cross-platform hobby stuff to people without requiring them having to jump through the hoops of downloading and running an untrusted native executable or messing around with C/C++ toolchains and build systems to build the stuff locally).
PS: WASM in the browser is also a good watchdog which punishes you heavily if your code gets to bloated ;)