wasm is a binary format that can be read by all browser.
WebAssembly is “a bytecode for the Web”
It’s a technology with the potential to become a truly multi-vendor, multi-platform, safe, polyglot programming platform.
You can therefore create a function in any language (java, php, …) and compile it to the wasm format to make it available in your page.
WebAssembly is defined as a virtual instruction set architecture (ISA) for a structured stack-based virtual machine. https://github.com/WebAssembly/design/blob/main/Rationale.md
In a structured stack machine:
- most computations use a stack of values,
- but control flow is expressed in structured constructs such as blocks, ifs, and loops.
It is a very significant departure from the way, say, the JVM works.
Moreover, in the WebAssembly language, some instructions can be represented both as “simple” and as “nested”.
with WebAssembly you get a slice of linear memory, and then you can do whatever you want with it. Allocate, deallocate; even move it around if you’d like. It is no coincidence that most languages targeting WebAssembly today really manage their own memory.
But there are also many standalone pure-WebAssembly runtimes such as:
many projects are starting to embrace WebAssembly as a polyglot platform to host extensions and plug-ins.
For instance Fastly has developed a platform for serverless computing at the edge, where the serverless functions are implemented by user-provided WebAssembly executables.
Fermyon is a startup that is developing a rich ecosystem of tooling and Web-based APIs to write Web apps using only Wasm
WASI is the WebAssembly System Interface.
You can think of it as of a collection of (POSIX-like) APIs that allow a Wasm runtime to interact with the operating system.
It is a thin layer of capability-oriented APIs for interaction with the operating system (one level below the jdk.
WASI allows to define backend applications that directly interact with the operating system without any extra layer, and without ad-hoc APIs. 1)
WASI APIs include things like:
- file system access,
- and even threading APIs.
These APIs work hand-in-hand with the lower-level capabilities of the runtime, enabling easier ports to the platform.
2) do not target Wasm, but still target browser runtimes:
- Kotlin/Native also supports being compiled to Wasm via LLVM. It comes with all the caveats of Kotlin/Native (e.g. it may not support all of your Java libraries)
Java as web assembly runtime
- graalvm truffle
- TeaVM ((https://github.com/fermyon/teavm-wasi - fork