WASM isn't actually itself dependent on a VM for execution. It runs in a VM in most implementations today, because it needs to cooperate with existing JS code running inside that same VM.
Also there are currently no ways for WASM to call out to Web-APIs directly from the host environment (or directly manipulate the DOM for that matter).
This will eventually get added, and then it would be possible to use just WASM without JS, but this has never been a goal, to make JS extinct (good luck with that btw).
Just because it is much faster to run highly optimized hardware specific compiled binary modules written in C for specific applications, doesn't mean that your Todo-List App would need the same blazing performance.
Obviously, most web apps DON'T belong in that "max-performance needed" category. Sure, they would run faster, but it wouldn't be worth it because of the massive amounts of existing code that would need to be re-written, staff would need education, blah, blah...
One primary objective is for WASM to be included in the common web-specs as a first class citizen, offering ways to develop fully compiled binaries, that can run, plugged into a variety of targets and primarily for use on performance critical applications, opening up for practically any app (ported from C, C++ etc) to use the web-browser as a target platform.
This will probably to be done using a libc-like approach, where the fundamental WASM libs will already be present within all major browsers, and the rest of the app would be directly executed at native execution-speed, while still running in the same semantic universe as JavaScript and allow synchronous calls to and from JavaScript.
That's the future of High Performance Web Development...
Thanks for the comment, I mentioned that WASM is a way to run more efficient code based on other programming languages (mainly C/C++) on the browser when JavaScript cannot help. It'll not replace at 100% as the use of the languages above is sort of overkill.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Click-bait and full of errors.
WASM isn't actually itself dependent on a VM for execution. It runs in a VM in most implementations today, because it needs to cooperate with existing JS code running inside that same VM.
Also there are currently no ways for WASM to call out to Web-APIs directly from the host environment (or directly manipulate the DOM for that matter).
This will eventually get added, and then it would be possible to use just WASM without JS, but this has never been a goal, to make JS extinct (good luck with that btw).
Just because it is much faster to run highly optimized hardware specific compiled binary modules written in C for specific applications, doesn't mean that your Todo-List App would need the same blazing performance.
Obviously, most web apps DON'T belong in that "max-performance needed" category. Sure, they would run faster, but it wouldn't be worth it because of the massive amounts of existing code that would need to be re-written, staff would need education, blah, blah...
One primary objective is for WASM to be included in the common web-specs as a first class citizen, offering ways to develop fully compiled binaries, that can run, plugged into a variety of targets and primarily for use on performance critical applications, opening up for practically any app (ported from C, C++ etc) to use the web-browser as a target platform.
This will probably to be done using a libc-like approach, where the fundamental WASM libs will already be present within all major browsers, and the rest of the app would be directly executed at native execution-speed, while still running in the same semantic universe as JavaScript and allow synchronous calls to and from JavaScript.
That's the future of High Performance Web Development...
Ooops, there goes gravity! Got to run!
Thanks for the comment, I mentioned that WASM is a way to run more efficient code based on other programming languages (mainly C/C++) on the browser when JavaScript cannot help. It'll not replace at 100% as the use of the languages above is sort of overkill.