wax is a tool intended to ease the use of command-line WebAssembly applications on your system. Similarly to wapm, that allows the installation and usage of packages and commands, wax enables use of CLI tools without installing them globally or changing your
The best thing about wax is that you will always run the commands on their latest version without having to handle updates, and because commands are not anywhere in your globals, you don’t have to worry about pollution in the long term. …
We started Wasmer with the mission of making programs universally available by leveraging on WebAssembly (Wasm). By enabling the use cases of Wasm outside of the browser we aim to unleash its full power: becoming the lingua franca for running software safely and at native speeds.
Linux and macOS were the first platforms we started supporting for executing Wasm server-side (since Unix support was the easiest to start with), to then add support for Windows just a few months after the initial launch.
Similarly, we focused first on running Wasmer in
x86_64 chipset machines, as it was the most popular chipset among developers (desktop computers, laptops, servers). …
At Wasmer we have been porting a lot of C and C++ projects to WebAssembly and WASI, as we believe WebAssembly will emerge as the standard way to use third-party code from any programming language securely and easily.
We realized that compiling already existing C/C++ projects to WASI was much more challenging than we expected. This is because of two main reasons:
Wasmer is completely focused on running WebAssembly modules server-side.
We started by running Emscripten-generated modules, but over time we added support for other ABIs (WASI, Wascap, etc).
You can run various programs with each ABI, such as Nginx (Emscripten) and Cowsay (WASI)
Over time we realized that the runtime had to do a lot of checks before starting an instance to verify that the WebAssembly module was compliant with a certain ABI (Emscripten or WASI). That means checking that the module imports and exports are what the runtime expects (namely the function signatures and global types match).
It turns out these checks are not just important for making sure a module is going to work with a certain runtime, but they can also be useful to assure a module is compatible with a given API. …
Two weeks ago we released the first version of WAPM (the WebAssembly Package Manager) and since then we got a lot of insight and traction from the community.
So we worked to make it possible in the latest version of Wasmer:
wapm install -g lua # The -g flag indicates a global install
And… you can run
wapm run lua
However …could we go one step further? …
Today, we are releasing a new tool that will help you use WebAssembly anywhere: WAPM (aka WebAssembly Package Manager).
This release includes:
wapm, included when you install Wasmer
Why: while working on Wasmer, we discovered that the developer ergonomics needed to improve significantly for WebAssembly to be accessible by the general audience. We realized that a Package Manager will help solve common problems like publishing, defining module ABIs, distributing executable binaries and using them.
What: WebAssembly is an abstraction on top of chipset instructions, this enables wasm modules to run very easily on any machine. If we move this abstraction up we can unlock the potential of having universal binaries that can run anywhere, even on platforms/chipsets not supported at the moment of releasing the binary. Integrations like WASI and Emscripten are essential for projects that want to target WebAssembly easily. …
Originally, the Wasmer runtime was designed around Cranelift, a compiler framework written in Rust.
Over time, we realized that different user-cases needed different compiler characteristics, so we’ve expanded our backend repertoire.
We now support selecting multiple compiler backends while exposing the same, familiar, simple API to the user.
Why would you want multiple compiler backends? Each backend offers a different tradeoff between compilation speed and runtime performance.
Today, we are super happy to announce that Wasmer 0.3.0 just shipped two more compiler backends 🎉:
wasmer run --backend=singlepass myfile.wasm
wasmer run --backend=cranelift myfile.wasm…
We’ve been working steadily to get Wasmer to execute WebAssembly modules on the server-side as fast as possible.
TL;DR — We got 100x improvement on startup time on Wasmer 0.2.0
Before getting into details, it’s essential to understand how Wasmer works under the hood to see what could be improved.
When a user executes a WebAssembly file with Wasmer, the following happens:
WebAssembly is a great technology. It brings ubiquity to our applications, so they can run anywhere: from browsers to servers, from Windows to Unix, from Desktop to Mobile…
…but not that fast though. 🏃♂️
So once applications are compiled to WebAssembly, how can we make sure they run on all platforms?
Or —in other words — what is the best ABI that all applications should target?
Let’s start from the beginning…
ABI stands for Application Binary Interface (wiki page).
We can see an ABI as a contract between two binary applications, to assure that one binary is able to access certain native functions from the other binary. …
We started Wasmer with the goal of running standalone, platform-dependent applications on any platform or architecture so that developers can focus on what really matters: reaching a bigger market faster with less effort.
For that, we realized that WebAssembly is the ideal technology to leverage:
WebAssembly has matured enough and this would be the best time to make something that will improve significantly developers’ lives
Wasmer is the first native WebAssembly runtime able to run most (soon all) WebAssembly modules compiled with Emscripten (including Nginx) regardless of the host system: Linux, OpenBSD or Mac (and soon Windows!). …