This post gives developers more insight into how Wasm is being used day to day and helps them make technical choices down the road.
By Renee Shah
When I tell people I’m interested in WebAssembly (“Wasm” for short), the most common question that I get is “how is WebAssembly actually being used?” That was the impetus for this post, which showcases the work of startups using WebAssembly in production. As with any emerging technology, half of the early battle is figuring out how and why to use a technology. I’m hoping this post gives developers more insight into how Wasm is being used day to day and helps them make technical choices down the road.
This post assumes some knowledge of WebAssembly, but if you need a primer, this one is fantastic. I reached out to 18 startups that were either using WebAssembly in production or building core infrastructure to develop Wasm applications. Every company answered two questions. Their responses to these questions are below:
I’ve also categorized every company into a few buckets:
Let’s dive in.
###Using Wasm — server-side
How are you using Wasm? We make Jamsocket, which allows developers to deploy servers on the fly for each user. We use OCI containers as the unit of deployment for compatibility with existing images, but we have a workflow for deploying WASM server modules using our open-source Stateroom package. We are experimenting with using WASM directly without Docker to improve cold-start times.
Why did you choose Wasm? Our core functionality depends on us spinning up servers in response to a user action, so cold start times are very important. Relative to Docker, WASM provides fast cold start times, and opens up interesting possibilities like moving running modules between nodes to load-balance running modules as their resource needs change.
How are you using Wasm? HASH uses WASM as our critical layer of common bytecode for our simulation engine. We write hEngine in Rust and include a Wasm compilation target, then call into WASM from our other languages, including Python and JavaScript, to access the common engine processing in any environment. By embedding WASM in our web application, we acquire a high performance simulation engine that can run code in-client, and can easily ensure consistent simulation behavior across multiple coding platforms.
Why did you choose Wasm? WASM actually informed the choice of Rust as our core platform programming language at the dawn of HASH. Knowing that WASM was iterating towards being an ever more portable, accessible, and efficient execution environment meant that we were able to trust both Rust and WASM to grow in the direction we needed. And indeed they have. We remain optimistic about WASM continuing to grow into a general common runtime and interop layer that’s accessible across languages and platforms.
How are you using Wasm? We use Wasm as part of our core product offering, Rune, which is an open source portable machine learning & compute container for the cloud & edge. We also use Wasm in our SaaS product to provide direct metadata and interfaces using Witx. Witx is an interface specification that makes it easier to integrate Wasm into a plethora of environments.
Why did you choose Wasm? We chose Wasm because we needed to provide portability across several devices and ML frameworks. Wasm also allowed us to secure compute workloads on the edge for our customers.
How are you using Wasm? Styra is commercializing Open Policy Agent (OPA). OPA allows compiling policies written in its Rego language into Wasm — for distribution to systems and platforms where calling the OPA REST API might not be feasible. The most common reason for this is performance, but it could also be due to resource or environmental constraints.
Why did you choose Wasm? One of the key ideas behind OPA is that it should be available everywhere and deployed as close as possible to the service it’s making policy decisions for. Wasm brings policy enforcement to environments where OPA previously would have been challenging to integrate, and opens up for many new, exciting use cases!
How are you using Wasm? Substrait is an open source project focused on exposing standardized compute plans across analytical systems to do two things: 1) Polyfill the capabilities of underlying analytical engines. Sometimes a function or operation in one system is not available in another system. WASM can supplement basic underlying functionality (making an operation available in one analytics engine available in another platform). 2) Embed user-defined business logic into a containerized package for SaaS applications. In data workflow systems like Pandas and Spark, users frequently embed business logic within a data transformation pipeline, but it can be difficult to move this logic. WASM is a way to package up these operations into a safe executable, allowing generic analytics systems to execute arbitrary user-defined business logic.
Why did you choose Wasm? Traditionally, systems have provided extension capabilities through a language specific SDK (frequently, Javascript via V8 or Java). However, these extension patterns suffer from several weaknesses: each language is an additional effort, the sandboxing models are often immature, and it’s difficult to understand compute costs. The most common modern SaaS approach has been through HTTP calls to external FaaS platforms. This approach solves sandboxing and performance, but throughput and latency still suffer. Systems like AWS Athena try to mitigate these problems with batching but ultimately external FaaS patterns pale in comparison to in-kernel processing patterns. WASM is the first foundational technology that provides near native performance on a SaaS service but has the underlying architecture to effectively manage both sandboxing and compute costs. We believe that these benefits will lead WASM to become the default model for extension of modern data systems.
How are you using Wasm? Tetrate is using Wasm to bring custom policy and security to Envoy, enabling advanced use cases for our service mesh customers. We’re helping enable Wasm with wazero — an ultra-lightweight, cross-platform, zero-dependency Wasm runtime that’s open source and fast.
Why did you choose Wasm? Two of the biggest advantages of the service mesh are moving functionality out of applications into the platform, which reduces developer workload, and moving functionality from the edge closer to applications, which facilitates a zero trust architecture. The power, popularity, and flexibility of Wasm help enable both for customers.
How are you using Wasm? DuckDB strives to make analytical SQL processing accessible for everyone. WebAssembly is a natural fit for us that’s fast and that extends our reach to millions of devices through the web. Our users appreciate our focus on performance in languages like Python and R and we are very excited that we can now deliver the same experience for Javascript.
Why did you choose Wasm? We are using WebAssembly to power DuckDB-Wasm, an in-process analytical SQL database for the web. Analytics in the browser has been thwarted by limited processing efficiency for decades, but WebAssembly has changed this. With WebAssembly, we can provide the full capabilities of DuckDB for Javascript and offer near-native execution speeds at a low latency.
How are you using Wasm? At Dynaboard, we use WebAssembly to make our multiplayer editor performant, secure, and powerful.
Why did you choose Wasm? WebAssembly is the most powerful and elegant sandboxing primitive yet. By compiling code to WebAssembly and selectively exposing APIs, platforms can safely run user-provided code in the browser at close-to-native speed. Increasingly, browser-based applications are using this approach to enable their rich plugin ecosystems, giving developers more power to extend these applications than ever before. Developers can use the programming language of their choice and tap into the power of package managers. What’s more, the same Wasm-based execution engines can run server-side to perform reliable server-side rendering at the edge. This isomorphic property of WebAssembly — the ability to compile code once and run it nearly anywhere — unlocks new possibilities for web platforms of all types. At Dynaboard, we use WebAssembly in both of these ways.
How are you using Wasm? We use WASM for some of our low-level media manipulation and effects rendering on our video editor.
Why did you choose Wasm? WASM allows us to leverage an existing and wide ecosystem of low-level media and graphics libraries. It also gives us the flexibility to reuse the same code client-side and server-side.
### Building Wasm infrastructure — server-side
How are you using Wasm? Right now, we’re experimenting with Wasm modules as a means of safely moving data transaction code or transformations to the client with capability-based permissions baked in. We also use AssemblyLift Wasm to serve our static landing pages and such from AWS Lambda (at virtually no cost!).
Why did you choose Wasm? Wasm has several properties that make it attractive for the backend and in client-side SDKs. Its simplicity is really the key, I think. It doesn’t come with the overhead of a container system or shipping an entire OS, can be embedded in other code, and it provides a sandboxed environment to boot!
How are you using Wasm? At Deno, we use WebAssembly in production extensively. We compile and distribute a lot of our Rust code to WASM so we can run it in sandboxed V8 isolates. One great use case is running it on the edge close to users, using our Deno Deploy product.
Why did you choose Wasm? One use case is our https://doc.deno.land/ service, which uses our Rust based “deno_doc” crate compiled to WASM to parse JS and TS source code and generate documentation from that. We use WASM because it allows us to share this Rust code between our Deno CLI (which compiles to native machine code) and our web services running on the edge in V8 isolates.
How are you using Wasm? WebAssembly is the foundational compute technology behind the Fermyon Platform. We are building a suite of tools that takes the best of serverless and provides an elegant developer experience. Wasm’s broad language support and extraordinary performance hit key sweet spots for microservice and web developers. How easy is it to use? We built a WebAssembly content management system in a weekend.
Why did you choose Wasm? Fermyon believes that WebAssembly is the next wave of cloud computing. Wasm compliments virtual machines and containers by providing a fast, secure, cross-platform compute engine that realizes many of the unattained goals of serverless. Wasm can squeeze into tiny embedded devices or take advantage of advanced features of datacenters, fitting its performance to the capabilities of the hardware. This is the right foundation for a next-generation compute platform.
How are you using Wasm? InfinyOn, an intelligent data streaming company, utilizes Wasm processing to perform real-time transformations on Fluvio and the InfinyOn Cloud platform. Data engineers can build modern applications with event stream processing and data transformation in a single unified cluster. Build innovative Wasm modules to ensure data quality with distributed intelligence and centralized control.
Why did you choose Wasm? Wasm offers full programmability for building intelligent data pipelines that unlock the creativity of data engineers. Alternatives such as SQL or APIs restrict data transformation capabilities and are limited in scope. Wasm’s flexibility allows for a broad range of transformations distributed across the network, whether cloud, mobile, or edge computing.
How are you using Wasm? Lunatic uses WebAssembly to bring Erlang’s features (massive concurrency, distribution and fault tolerance) to many different programming languages. We believe that Erlang is a superpower, and with Wasm we want to give this superpower to all developers, no matter their programming language of choice.
Why did you choose Wasm? One of Lunatic’s core features is lightweight isolation, so security aspects of Wasm are crucial. Because of them, Lunatic can run many Wasm programs concurrently, even if some of them are malicious. It would be impossible to build a platform like Lunatic without WebAssembly.
How are you using Wasm? Profian is the custodian of the Enarx open source project. Our goal is to render Confidential Computing accessible. By using Wasm, we make it easy for developers to deploy their sensitive applications and data to the Cloud with cryptographic assurances, offering a wide range of language choices for implementation and abstracting away the different silicon architectures that support Confidential Computing.
Why did you choose Wasm? Wasm and Confidential Computing complement each other perfectly, as Wasm provides a sandboxed environment which protects the host from a buggy or malicious application, while Confidential Computing provides a trusted execution environment which protects the application from a compromised or untrusted host.
How are you using Wasm? Second State is helping customers deploy our runtime, WasmEdge, for several use cases: 1) microservices in Kubernetes clusters (eg OpenYurt, SuperEdge, KubeEdge), 2) serverless functions to render frontend UIs on edge servers (ie, SSR functions), 3) as application runtimes on mobile devices (eg Android and Open Harmony), and 4) as smart contract runtimes on blockchains (eg Polkadot, ParaState, Oasis, and FileCoin).
Why did you choose Wasm? WebAssembly is a high-performance, lightweight, and polyglot application “container” widely supported by industry standard container management tools. We use it to expand the cloud-native programming model to resource-constrained and performance-sensitive environments, such as the edge cloud, embedded / serverless functions platforms, blockchains, as well as mobile and IoT devices.
How are you using Wasm? We’re using server-side WebAssembly to flip the development of cloud applications on its head. Developers should be able to focus on what makes their application unique, not its security or scalability. By tightly controlling the Wasm sandbox and putting its lightweight nature to good use, we’re ensuring that developers can build and deploy systems that are simple to understand, inherently secure, and scale instantaneously.
Why did you choose Wasm? Nothing we are doing would be possible without WebAssembly. Building on a new technology that includes the best of virtualization, security, and performance means that we can achieve kinds of system design that were simply not available during the VM or Container eras. With the rising tide of Wasm adoption in the cloud native space, we believe that it will become a commodity in the same way, and it will democratize the ability to build systems that are currently only available to tech behemoths.
How are you using Wasm? Zaplib is a Rust Wasm framework that programmers use to speed up their web apps by rewriting their slow JavaScript functions into Rust and compiling them to Wasm. Zaplib provides a Wasm-safe standard library for Rust, efficient APIs for sending between Wasm & JS, and graphics APIs.
Why did you choose Wasm? Wasm is the enabling technology that allows using Rust to speed up web apps. WebAssembly is faster than any other approach in the browser. Our entire framework and business wouldn’t exist without it.
That was a quick look at how Wasm is being used today, client-side and server-side. Here are some opportunities I see for the future. As you’ll see, these ideas aren’t fully baked, but I hope they’ll spur some good discussion:
Figma, Autodesk, and Google Earth have all built amazing browser experiences with WebAssembly, yet it’s still non-trivial for developers to do the same without the support of big company budget and expertise. I still see a few areas of opportunity to make the client-side Wasm experience better:
Several of the startups in this post are making it easier to build and deploy WebAssembly applications. These companies have accomplished a lot in a short time. Here are some more opportunities moving forward:
Feel free to reach out to me on Twitter @reneeshah123 to chat more about these ideas. Also, I am deeply grateful to my colleague, Justin Gage, for reading and editing this post.