Wasmer Inc (the company) has released Wasmer 3.0, the latest version of its open source runtime for WebAssembly (Wasm). The new release can compile Wasm to native executables for Windows, Linux or Mac, without any runtime dependency.
Founder Syrus Akbary says that the new release also has the ability to run WAPM (WebAssembly Package Manager) packages directly with “wasmer run”, a newly rebuilt Rust API, and improved support for WASI (WebAssembly System Interface), which adds file I/O and other features to the WebAssembly for running outside the browser.
WebAssembly was originally designed as a means of running code written in other languages, such as C/C++, within a web browser, safely and with near-native performance. JavaScript runtimes are now often used on the server as well, such as in Edge functions or Cloudflare workers, and Wasm fits neatly in this context. Wasmer is another way of running Wasm in non-browser contexts, offering a potential alternative to other cross-platform runtimes, such as Java.
Wasmer describes itself on GitHub as “a fast and secure WebAssembly runtime that enables super lightweight containers to run anywhere: from Desktop to the Cloud, Edge and IoT devices.”
The create-exe Wasmer command, described in preview here, compiles Wasm with some glue code and then “we use a C compiler/linker file to join everything together,” according to Akbary’s post in August this year. The result is a standalone executable, “a binary that is completely sandboxed and with minimal runtime overhead.”
The languages which Akbary mentions as suitable for create-exe, such as Rust, Go, C/C++ and C#, can also be compiled to run on these same platforms, and likely with better performance. Does Wasmer therefore bring any advantage? Akbary said that automatic support for new chipsets is an advantage, “so when new chips and operating systems appear, we don’t need to worry about recompiling our software.” Another advantage, he said, is safety via the Wasmer sandbox.
Despite these claims, there is some scepticism in the community. Performance versus native code is one issue. “In general I’ve found it to be 2-3x slower, at least for my use cases” said a developer on Hacker News. Others are more positive. The notion of being able to call libraries written in one language from an application written in other language is attractive. “It’s often the case that people choose languages based on the availability of the libraries written in those languages. The goal of non-browser WASM is to get rid of that and to minimize the friction of inter-language communication,” said another dev.
The biggest attraction, perhaps, is the potential of Wasm sandboxing to reduce the need for containers on the server. Containers are lightweight in comparison to virtual machines, but still with a substantial overhead.