1. While true, in practice what I have tested it is that the performance is very, very rarely worse (although often it is negligible difference). The thing is wasm performance is predictable. This is really important for graphics and games since there is no JIT going on, JS (and python, ruby, etc) performance can vary widely based on how often a codepath is used
2. This is planned to change with Interface Types which will let you call any DOM method from any wasm code without without custom bindings and performance hit as well as, for example, calling a python module from golang for example (as long as both are compiled to wasm)
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support.
the main point of wasm outside of browsers is sandboxing and compatibility, a whole set of applications become possible when you have that. A simple example are SaaS application that let users upload wasm plugins that run on the SaaS application servers
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support.
wasm is just one part of the puzzle, the other one is WASI which is poised to become a standard interface for OS interaction. With it you could conceivably have a single binary for any OS+processor architecture (as long as there is wasm runtime + the parts of WASI required by your app implemented). This is huge for embedded development, I myself spent insane amounts of time trying to get shit compiled to different OS+architecture
2. This is planned to change with Interface Types which will let you call any DOM method from any wasm code without without custom bindings and performance hit as well as, for example, calling a python module from golang for example (as long as both are compiled to wasm)
I recommend this article about it: https://hacks.mozilla.org/2019/08/webassembly-interface-type...
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support.
the main point of wasm outside of browsers is sandboxing and compatibility, a whole set of applications become possible when you have that. A simple example are SaaS application that let users upload wasm plugins that run on the SaaS application servers
> If you don't do frontend stuff, you don't have to use WASM, you know? You could just go native binary in the first place especially as modern languages have great cross-compilation support.
wasm is just one part of the puzzle, the other one is WASI which is poised to become a standard interface for OS interaction. With it you could conceivably have a single binary for any OS+processor architecture (as long as there is wasm runtime + the parts of WASI required by your app implemented). This is huge for embedded development, I myself spent insane amounts of time trying to get shit compiled to different OS+architecture