The alternative is that it's a bloated piece of tech that ends up the way of Flash/Applets.
I.e. disabled and eventually removed? I could live with that.
I believe flash and java applets were something else than WASM.
Right, they were their own separate VMs, with a lot of duplicated functionality. WASM is just a way to get native, non memory managed languages executing efficiently in a JavaScript environment.
Now that makes me wonder what the point of WASM is because we could have always transpiled code to JS
Performance. WebAssembly has no JIT stage, it gets AOT compiled straight to machine code. Plus, it gives (or will give) much lower-level access to features like threads and memory allocation.
> Plus, it gives (or will give) much lower-level access to features like threads and memory allocation.
There's no reason JavaScript couldn't just have those features. It already has some amount of memory allocation control via ArrayBuffer & DataView.
You're describing asm.js which had significant issues as a compilation target. The generated javascript code was massive and it took several seconds just to parse it.
asm.js never added threads, which is a far bigger performance issue than fine-grained manual memory allocation is.
Thanks to Spectre I don't think we'll be seeing threads anytime soon. Well, not threads with shared memory anyway which removes a lot of the point of them. Same reason JavaScript just lost SharedArrayBuffer, too easy to make a high precision timer out of it.
Right now, some of the biggest users are applications where JavaScript's garbage collection pauses are show-stoppers, like games and audio recording software.
Transpilation to JS always sucks. JS was not designed as a compiler target. The point of WASM is exactly that: Compile any language on the web without getting into the JS limitation.
Is that just the current state of affairs, or will it always be like that?