Why would I want to compile my app to WASM if it's not running in a browser?
For serverless usecases, cloudflare etc.. found that it would be faster to just call a function from a wasm binary than spin up a whole docker container [1]. Which basically translated to cost savings.
In the last company I worked for [2], we saw wasm as a way to easily ship user code in a cross platform way. We mostly targeted edge-ml use cases. Wasm allowed us to package all the "libraries"/functions needed to run the user code securely. So users created and tested out their ML apps in browser and deployed them to all the platforms we supported. (Mobile, Browser, Embedded). As an added bonus they could write each of their functions in any language that compiled to wasm, and just ship it as one "app".
1. https://blog.cloudflare.com/cloud-computing-without-containe... 2. https://hotg.dev/
Are there realistic benchmarks that quantify these gains?
A first view of the promise reads reminiscent to the JVM days, which promised to solve portability. The main difference is JIT vs. AOT, but hidden behind that remains also the complex management of FS access, threading, spawning, SIMD, GPU, and other unportable differences. While I imagine that the shim would avoid having a whole Linux, what do we lose in the change?
Most images nowadays have ARM version, so probably that's how most people use it.
Although; do we need a compiler for Java? It may be going full circle.
> One benefit of using wasm is architecture-agnostic binary. Right now you can't run x86 binary on ARM or vice-versa.
That was the advantage given for the JVM. The .jar ran on x86 and ARM.
Running raw WASM is similar to running Java bytecode, but with fewer cross-platform APIs.
Yes, we need a compiler for Java. Java sources are compiled to Java bytecode along with many other actions for complex projects like downloading dependencies, generating sources, running tests which might run platform-dependent binaries and so on.
> That was the advantage given for the JVM. The .jar ran on x86 and ARM.
Yes, wasm and Java bytecode are the same in that regard. But Java bytecode failed to get adoption outside of Java world. Wasm might not, we will see. One significant improvement of Wasm over Java is good security story. Java sandbox is well known for its CVEs. Browser wasm implementations are battle-tested on billions of devices in the wild Internet. So you basically can't run untrusted Java bytecode without further boundaries like KVM or at least containers. But you definitely can run untrusted Wasm bytecode because that's what your browser does all the time.
A bigger peeve is that there is no general reasonably fast cross build ability, to eg build, test and debug ARM images (for runnign on ARM servers) on x86 Linux or Windows etc.
There's Rosetta emulation and qemu emulation.
Rosetta emulation is quite fast. But docker does not use it. At least for now.
qemu emulation is extraordinarily slow and basically unusable for anything but the simplest code.