Forrester Research recently produced “WebAssembly Wisdom: Best Practices for Wasm Wizards” (March 15, 2022, by Andrew Cornwall with Chris Gardner, Emma Goldberg, Zachary Stone, Kara Hartig) that offered advice about what to do and what not to do when contemplating Wasm development.
As Andrew remarked in his blog, “I am confident that bytecode is back and WebAssembly is here to stay… While WebAssembly emerged from a desire to improve the performance of computationally intensive browser apps, it can do much more than that.”
He blogs about multiple use cases in which developers can use Wasm to transform their products and processes, without waiting for Wasm to continue to evolve. The processor-agnostic execution target running at near-native speed on both the client and the back end to:
- Overcome the performance limitations of JavaScript in the browser
- Accelerate server side functions and services
- Enable portability and sandboxes
I agree wholeheartedly with the sentiments of Stuart Harris, Red Badger founder and Cosmonic partner, quoted as saying “[Wasm] is infiltrating every single area of computing. ... It’s absolutely crucial to the next few years.”
Forrester Research believes that Wasm will be a useful tool on both clients and servers, with its displacement of JavaScript unlikely. For situations where a great deal of computations is needed, Wasm is recognized as a viable approach to solving problems that JavaScript can’t.
To start exploiting the power of Wasm, Forrester advises its enterprise clients take memory strategy and its current limitations into consideration exploring the use of WebAssembly for the following use cases:
- Jump-Start Your JavaScript - if you have compute-bound JavaScript code that can be converted, Wasm can help. Moving to Wasm is usually most effective when calling a subsystem. Calling Wasm from JavaScript has its own overhead. While using Wasm to port an existing library that is written in a language other than JavaScript to run on the browser, it won’t help if the problem isn’t with code speed. Wasm will provide only a marginal boost to performance if you’re encumbered by a slow server, transferring large images, or implementing a poor design.
- WebAssembly Blended with JavaScript is Effective - consider using both Wasm and JavaScript where they’re both suited. Wasm is not a replacement for JavaScript; it’s best reserved for compute-bound methods and subsystems.
- Use WebAssembly to Strengthen Your Back End – it’s easy to integrate, considering most cloud providers for serverless functions and writing in Rust or C/C++, provide support for Wasm already.
Among best practices, Forrester recommends its enterprise customers to:
- Avoid starting traditional containers for WebAssembly, where possible, since the container incurs significant penalties in startup time (milliseconds vs microseconds).
- Secure your environment with WebAssembly System Interface (WASI) capabilities . Tyler McMullan, CTO at cloud computing services provider Fastly, is quoted as saying, “If you’re not using WASI, you’re definitely making a mistake. In the same way that on Linux you shouldn’t be writing your own syscalls, you should use what exists.”
- Omit threading for now , as Wasm doesn’t currently support multi-threading.
- Use WebAssembly for cloud resilience and diversity to attain platform independence from microprocessors and cloud providers alike
Red Badger has demonstrated work for a large European bank in which Wasm workloads failed over from GCP to AWS and back using wasmCloud and NATS.
For more pragmatic insights, Forrester customers can reference Andrew’s reports. I also welcome everyone to register for CNCF WasmDay on May 16th, co-located with KubeCon EU.
The agenda will be announced soon.