If you are an ambitious person, you will realize that reaching your goals not always implies reaching happiness but sometimes quite the opposite… but why is that?
As an ambitious person myself I used to be driven by a strategy that I believe is also common in people with the same trait:
Imagine where you would like to end and draw a mental map of how to get there
However, over time I realized that this strategy is not the optimal if we intend to maintain a happy life while attempting to reach our goals.
Here’s my story:
It’s been two years since we published the first line of Wasmer code, the first server-side WebAssembly (Wasm) runtime able to run Nginx server-side.
We believe that WebAssembly will be a crucial component for the future of software execution and containerization (not only inside the browser but also outside).
By leveraging Wasm for software containerization, we create universal binaries that work anywhere without modification, including operating systems like Linux, macOS, Windows, and also web…
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…
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…
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…
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…
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.
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.
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:
Entrepreneur. Developer. Mathematician