In a Javascript ecosystem, WebAssembly and WASI can play a similar role as native DLLs in Python (or also the role native DLLs are playing in the NPM ecosystem). You can load WASM modules from Javascript code, and those WASM modules can interact with the underlying system via WASI.
This enables some new scenarios:
- You want to use an existing library, but this library isn't available in Javascript. Instead of porting the library source code over to JS, compile it to WASM and call into the WASM module from Javascript.
- You've optimized some piece of JS code, but hit a performance or readability wall (often, JS code optimized for performance is much less readable than "idiomatic" JS). You can port the code to C and compile to WASM instead, this might push the wall a little bit further (not as far away as native code would allow, but often quite close).
The main advantage of WASM+WASI over native DLLs is that they are OS and CPU independent. You don't need a DLL built for each possible OS+CPU combination, instead just compile once to a WASM module.
WebAssembly implies a model with no syscalls. WASI provides a basic set of POSIX like syscalls which is used by the various standard libraries when the compilation target is wasm32-wasi.
So C, C++, Rust code using their respective standard libraries compiled to wasm32-wasi can run on Deno out of the box.
Essentially, yes. WebAssembly code runs at near-native speed yet is unable to crash the host process / clobber its memory etc, so this is a viable alternative to FFI for most use cases.
Well, I merged deno-wasi into deno about week or two ago, currently shipping in stable.
Please feel free to break it :)