The Three Pillars of WebAssembly – InApps 2025

There is a rising tide in the software industry around WebAssembly. Commonly known as WASM, this technology is changing the way our code is executed in environments such as the web browser, edge cloud, IoT devices and more. I’ve written about different aspects of WebAssembly in the past, so give those a read if you’d like more context.

Today I will talk at a high level about what makes WASM special, why you should care about it and why I believe it will be powering a new generation of software for years to come. I will lay out the three pillars of WebAssembly — security, portability and performance — and give you an overview of why they make WASM a force to be reckoned with.

Security

Let’s start with security. It’s at the forefront of many minds these days, with supply chain issues, cryptojacking and data breaches being common news stories. WebAssembly brings some big guns to the security fight in a number of ways, starting with its security sandbox.

When WASM is executed, the code is not given access to anything, including the network, file system or anything else out of the box. This is known as a deny-by-default security model, and it’s not something implemented by container technologies such as Docker. For the code running inside the WASM sandbox to interact with the outside world, it must be explicitly granted access to host functions.

The web browser can grant a WASM module certain abilities such as the fetch API and access to the DOM. Other hosts like cloud environments can use WASI (the WebAssembly System Interface) to grant the module access to the file system, randomness (like /dev/urandom) and common things like the system time. All of this ensures that the code inside a WASM module is only given access to the resources it needs to operate and nothing more.

To combat the rise of supply-chain attacks, there are also efforts to make cryptographic signing of WebAssembly modules a standard part of the specification. The ability to sign a module with a trusted key and have that signature verified any time a system attempts to run that module will be a big win, and helps cement the “defense in depth” mindset when working with WebAssembly to build applications.

It will become especially important when software vendors begin distributing their API libraries as WASM modules; we’ll be able to take advantage of cross-language module linking (the ability for modules built from different languages to share memory and functions), but also verify that the module was produced by the vendor and has not been tampered with.

Portability

The idea of linking modules brings us to the second pillar, portability. I like to think about WASM’s portability in two ways: language portability and platform portability. Language portability is the ability for modules written in one language, like Rust, to run inside a system written in another, like Go. Because WASM runtimes can be embedded within other software, they can be used to introduce specialized components that wouldn’t otherwise be possible in your team’s primary language. This concept can also be applied to applications that are built by composing together multiple WASM modules written in different languages to form a single piece of software, such as with the Atmo framework, which our company, Suborbital maintains.

In regard to platform portability, WebAssembly is not tied to any hardware architecture, so it can be executed on several different platforms without needing to re-compile. This would allow you, for example, to produce a single WASM file and run it on both an IoT device and a cloud virtual machine. When a WASM module is executed, it is compiled to machine-native code either ahead-of-time (AOT) or just-in-time (JIT).

WASM runtimes such as Chrome’s V8, Wasmtime or Wasmer perform this compilation automatically, which makes running any module very simple. I can see this becoming useful in scenarios where your code gets moved automatically from a central cloud instance to an edge compute network when a spike in traffic causes a certain module to be pummeled by incoming requests, for example.

Performance

That leaves us with the final pillar, performance. WebAssembly is intended to execute code at native or near-native speeds. There are a number of factors that play into the performance of any application, including language, hardware, garbage collection, virtualization and more.

WebAssembly is a representation of your code that can easily be executed in a high-performance manner by optimizing itself for each platform at runtime. We are still in the early days of WebAssembly, but it is already rivaling the performance of the V8 JavaScript engine, which has been optimized over countless years. All languages that compile to WebAssembly will benefit from any future performance improvements brought to WASM runtimes, which is a big win for everyone.

I invite you to think about the software you’re building and ask yourself what aspects of your development platform are most important to you. I’m willing to bet that at least two of the three pillars that I discussed here are a key factor to your business, and that you would be able to improve upon your code’s key attributes by adopting WebAssembly as a technology. The hope is that WASM will become an underlying technology that powers software workflows without developers needing to care much about it at all, just as the majority of developers don’t concern themselves with the assembly code generated by their language’s compilers today.

The main difference is that WebAssembly has these great properties built in from the start to ensure your code is secure, portable and performant by default, which cannot be said for today’s software tooling.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.

Feature photo by Kevin Jackson on Unsplash.