- Runtime and compiler performance is out of this world.
- New features include better error handling, a more powerful API, cross-compilation, headless Wasmer and so much more!
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 browsers. Wasm automatically sandboxes applications by default for secure execution, shielding the host environment from malicious code, bugs and vulnerabilities in the software it runs. Wasm also provides a lean execution environment enabling Wasmer containers to run in places where Docker containers are too heavy to work.
Today we’re super excited to release Wasmer 1.0, featuring:
- Production-ready performance
- Pluggable Infrastructure
- Native Object Engine
- Headless Wasmer — ideal for IoT
- Super easy-to-use and extensible API
- Wasm-C-API support
- Error handling and debugging
Now let’s dig deeper into each of these new features!
Wasmer 1.0 performance benchmark requires a standalone post. A complete analysis of Wasmer compared with other Wasm runtimes for you to compare and choose what’s best for your project is in the works!
But, to give you a sneak peek, the numbers look good, really good!
Up to 9x faster compilation times with Wasmer 1.0
All our compilers now compile functions in parallel. Thanks to this new strategy, we achieved up to 9x speedup in compilation times across all our compilers.
- Singlepass: from 18s to 2s (9x speedup)
- Cranelift: from 27s to 9s (3x speedup)
- LLVM: from 1140s to 117s (9x speedup)
When using the Wasmer CLI, compilation happens only once and then the result is cached for optimal future runs.
Extensibility is one of the most critical features of any infrastructure product. One of our most vital capabilities is support for multiple compilers. The ability to select and plug-in the compiler that best meets customer use cases is incredibly powerful. Wasmer 1.0 ships with out-of-the-box support for:
- Singlepass: for ultra-fast compilation times not susceptible to JIT-bombs (ideal for blockchains).
- Cranelift: for fast compilation times where minimal optimizations are needed (ideal for development).
- LLVM: for optimal generated machine code when top performance is a must (ideal for production).
In addition to compilers, we introduced support for pluggable engines. A WebAssembly engine is an abstraction that decides how to manage the generated assembly-code by the compiler, including how to load and serialize it. Wasmer 1.0 supports the following compiler engines:
- JIT engine: it pushes generated code directly into memory.
- Native engine: it generates native code that can be loaded as a shared object. As a bonus, native engine shared objects and modules are incredibly performant and startup in just a few microseconds!
Native Object Engine
Wasmer 1.0 introduces “
wasmer compile”, a new command for precompiling Wasm files. Our customers and developers use “
wasmer compile --native” to precompile WebAssembly modules into native object files like
.dll. Precompiled objects and modules are compatible with the Wasmer CLI or used with Wasmer Embeddings (Rust, Python, Go, …).
A core advantage of precompiled native objects is that they only need a minimal runtime to run compiled modules, while still providing a fully sandboxed environment. Eliminated compilation time allows direct execution of the artifact at blazing-fast startup times.
wasmer compile --native python.wasm -o python.so
For standalone execution run:
wasmer run python.so
Or run embedded (Rust example…many others supported):
let module = Module::deserialize_from_file(“python.so”);
let instance = Instance::new(module, &wasi_imports);
It’s no secret that IoT devices running at the edge are driving the future of computing. However, many devices lack optimal computing hardware or other resources like power, network, and storage. In the past, users shipped their Wasm application with Wasmer and all compilers attached. This practice was suboptimal, especially for IoT and edge computing use cases.
With Wasmer 1.0, we see Wasm and Wasmer leading the charge in delivering the most lightweight execution environment possible, essential for efficiently running Wasm on IoT devices at the edge. With our newly-added support for AOT (Ahead Of Time) compilation, you can run a “headless” version of Wasmer that weighs just a few hundred kilobytes and runs any precompiled Wasm binary on any device.
Wasmer 1.0 now features cross-compilation. In the previous versions of Wasmer, natively compiled Wasm applications targeted and ran on the same architecture. With Wasmer 1.0, you can precompile Wasm for an
aarch64 architecture from an
x86_64 machine and vice-versa.
x86_64 machine run:
wasmer compile python.wasm -o python-arm.so --native --target=aarch64-linux-gnu
Then run the compiled result natively on your ARM machine:
wasmer run python-arm.so
Note: On the last step, “
wasmer run”, you can also use a headless version of Wasmer that is much more lightweight! (or you can run it embedded as demonstrated before)
Very easy to use API
A primary goal for Wasmer 1.0 is to make APIs very easy to use for developers that have limited knowledge of advanced WebAssembly concepts or the WebAssembly ecosystem. Wasmer 1.0 further improves our API, making it future-resilient by shaping it based on similar structures that the standard Wasm-C-API has.
As the WebAssembly ecosystem matures, the industry will rightfully push and unite APIs that interact with WebAssembly. Early in our journey, the Wasm-C-API was still very young, so we decided to build an API that closely matched our internal structures.
However, as the industry moves towards a universal API, we’ve decided to adopt it as a part of Wasmer 1.0 as well as contribute into it so everyone can benefit.
Note: we are continuing to support the Wasmer-C-API. However, we recommend current users to switch to the standard Wasm-C-API.
Error reporting and handling
Wasmer 1.0 completely reimagines and delivers a new and improved error handling feature that lets developers integrate with Wasmer with confidence. Significantly improve the time it takes to build production-ready Wasm applications. For instance, each time an error occurs, know precisely where the error is coming from: is it the Virtual Machine? Is it because there are not enough resources available? Or is it merely an expected error triggered from some of your host functions? Wasmer 1.0 lays the foundation for more advanced error detection and reporting in the future.
Apple Silicon Support
In the immortal words of Steve Jobs, “One more thing.”
Just a few weeks ago, Apple launched its new line of computers with a completely new chipset based on ARM: Apple Silicon.
ARM in server-side workloads has an incredibly bright future, and it solidifies the need for universal-binaries across chipsets. We are super happy to announce that Wasmer is the first non-interpreted server-side WebAssembly VM to support Wasm in Apple Silicon!
Wasmer 1.0 is already being used and tested by companies and individual developers across the globe. We want to thank all of them for helping materialize Wasmer’s vision for pushing Wasm forward.
As you have read in this article, Wasmer 1.0 showcases the numerous development cycles and iterations where we improved upon what we learned over the last two years. Wasmer’s current incarnation would not have been possible without companies like Google, Mozilla, Cloudflare, and Fastly (to name a few) pushing WebAssembly forward.
If you would like to try Wasmer, you can install the CLI from wasmer.io to run Wasmer standalone or embed Wasmer in your favorite programming languages.
Headquartered in San Francisco, CA, Wasmer Inc. is the company behind the popular open-source WebAssembly runtime Wasmer. In addition to the Wasmer runtime, the company has made significant investments in WAPM, the WebAssembly Package Manager, and many other open-source projects in the WebAssembly ecosystem.
Our mission is to make software universally available. We are committed to the open-source community and strive to contribute to developers and companies worldwide to help make Wasmer and WebAssembly a universal standard.