WebAssembly Extensibility: Today and Tomorrow

Photo by Denys Nevozhai on Unsplash

WebAssembly Extensibility: Today and Tomorrow

How Wasm is creating new possibilities in and out of the browser

Laura Langdon's photo
Laura Langdon
·Apr 29, 2022·

5 min read

Table of contents

  • Security—you can run it in a (sand) box
  • Portability
  • Performance—it is so good, so good you see!
  • Language freedom
  • Boundless flexibility with WebAssembly extensions

WebAssembly (or Wasm) is powering massive extensibility both in and out of the browser. With Wasm it's possible to write your app in (almost) any of your favorite languages and run it (almost) anywhere, without needing to worry about security or performance. Read on to find out how Wasm can make the software you build infinitely flexible!

If you aren't already familiar with WebAssembly, welcome to the community! We're excited you're here. For more background on what Wasm is and why it was created, check out our Tour of the Wasm Ecosystem, and we’d love to see you over at Wasm Builders, a blogging platform and community space for anyone interested in WebAssembly to learn, show off what they're working on, and discuss the technology.

Security—you can run it in a (sand) box

In fact, you can't run WebAssembly code outside of a sandbox. Security is one of the founding principles of Wasm, rather than an afterthought. This inherent security means developers can spend more time creating fantastic user experiences and less time on security.

Portability

You can run it with a (Fire)fox

All modern web browsers support WebAssembly! And Mozilla is a major contributor (along with Fastly, Intel, Red Hat, and many others, including we at Suborbital!) to the Bytecode Alliance, an open source community dedicated to the WebAssembly project.

You can run it here and there

Wasm is architecture-agnostic, running on any hardware for which there's a WebAssembly runtime (and there are many!). And Wasm apps can run on Windows, Linux, and macOS, so the same code can run natively on both mobile and desktop devices. WebAssembly can also run on the server-side and on the edge, as demonstrated by our own Sat project.

Performance—it is so good, so good you see!

WebAssembly code is low-level, close to machine code. When code is compiled into a Wasm module, it takes up less space, so it's faster to send across networks, and it's quick to parse. Wasm code reduces the need for optimization at build time because Wasm modules are strongly typed, and also optimized when their binary code is generated. WebAssembly has been designed with contemporary architectures in mind, and making use of common hardware capabilities allows it to execute code at near-native speeds.

A rollercoaster called 'Turbo'.Photo by Charlotte Coneybeer on Unsplash

Language freedom

Since Wasm is broadly supported for C, C#, C++, .NET, Swift, Go and Rust, and the community is building support for Javascript/TypeScript, Python, Ruby, and more (check out Fermyon’s handy table of Wasm support), developers have the freedom to write code in whichever of these languages they already know and love. And the modularity of WebAssembly engendered the nanoprocess model, which allows devs to import multiple secure and efficient WebAssembly modules and compose them to make an application.

Boundless flexibility with WebAssembly extensions

There are pretty much unlimited use cases for Wasm, but let's hear about one many of us have already interacted with, even if we didn't know it! The security, performance, and flexibility of Wasm made it the ideal choice for Shopify’s ecosystem. Staff Developer Saúl Cabrera filled me in on how WebAssembly has made new possibilities available at Shopify:

With WebAssembly, in the best case, we can afford to have small, composable programs, which helps when designing and using WebAssembly in performance-sensitive contexts like Shopify's Checkout for example. The newest WebAssembly proposals, like the Component Model, help us factor out common functionality and provide it at runtime via dynamic linking, allowing us to have very tight limits on the size of the binaries that partners can deploy to our platform.

A good example of composability at the WebAssembly layer would be using dependencies like a date library for example, given how common a library that provides this functionality is, we can extract it and provide it at runtime as part of our execution environment. That means that any program trying to use this functionality only needs to import it, as they would import some functionality from from an operating system. This allows us to avoid having to deal with big WebAssembly modules, which increase the storage and transfer complexity.

Saúl’s sentiment echoes our founder Connor Hicks’ thoughts in a post he published this week on how WebAssembly makes User-Defined Functions faster and more secure. Figma also made a similar shift when security concerns lead them to switch to cross-compiling to Wasm to run their JavaScript plugins, effectively doubling down on WebAssembly after previously adopting it to decrease load times.

Similarly, Istio has built extensibility into their Envoy proxy using WebAssembly, to get in on that “efficiency and security” action, and Solo.io has created WebAssembly Hub, a community space and central collection point for Wasm Envoy plugins. Relative newcomers to the WebAssembly family, Lapce and Zellij are using WebAssembly together with WASI features to allow their users to create their own plugins for their coding editor and terminal window multiplexer, respectively.

The ability to allow users to push custom code safely, quickly, and simply also informed Redpanda’s choice to build their data transformation engine with Wasm, and our own Suborbital Compute platform capitalizes on these Wasm characteristics to let customers run custom user code in their company’s infrastructure, while keeping that infrastructure insulated from any malicious intent.

Since WebAssembly was first released five years ago, the work and dedication of the Wasm community has grown it from an MVP into a tool that is now continuously expanding the boundaries of what’s possible with new standardization efforts like WASI. We spoke to Alexander Gallego, the CEO of Redpanda to better understand his predictions for the future of Wasm:

"Wasm will do for serverside what JavaScript did for the web in the 90's. For us Wasm allows us to expose a safe, programmable API to the internals of Redpanda”

This is an exciting time in WebAssembly, and we’d love to hear what you think the future will hold for Wasm! Feel free to chat with us with in the comments, and if you're keen to get started working with WebAssembly, check out these resources to get started! And for even more Wasm extensibility goodness, check out our stream from last week.

 
Share this