It’s Wasm’s World
***Felicis is excited to lead the seed investment into Dylibso. Our thoughts on the investment can be found here.***
The year is 2028. Your alarm goes off and you roll out of your slightly too-low-to-the-ground cot and look out on the horizon – the sun is just starting to peer out over the Indian ocean.
After your morning coffee, you open up your laptop and see the load screen from Last of Us Part IV. Not having the stomach to battle Cordyceps zombies at night, you decided to save it for the morning, when a fresh mind (and nervous system) would benefit you. As a remote engineer for Netflix, you know you have ~90 minutes of game time before the rest of your team logs on. And mornings are for multiplayer mode.
Not only is the ability to play multiplayer mode with your friends on your laptop made easier by WebAssembly (‘Wasm’), so is your job.
Remember the complexity (and time) required to rewrite the game code for desktop and mobile deployment? Or the long days (and nights) of having to work with the JVM?
Wasm simplifies this by bringing a highly portable instruction set, supported by major browsers with runtimes, that works on all major web architectures, with little to no overhead. This saves you and your team time, and most importantly unlocks more Last of Us time. Write once, deploy anywhere.
Those holiday hours spent managing server load? A thing of the past—Netflix’s architecture now dynamically scales to meet the demands of users, regardless of location or time.
And all of this…gaming, coding, deployment, is now done in the browser. Powered by Wasm.
Logically, you may be wondering, what is Wasm? How do we get from the reality today, to tomorrow’s vision? And how does WebAssembly help bridge the gap? In this post, I’ll distill:
→ What WebAssembly is (and why you should care)
→ How this helps companies (and consumers!)
→ Different approaches to commercializing this technology
What is WebAssembly? And why should you care?
The internet today is largely powered by Javascript (js). Almost all websites, web pages, and programs use js—a programming language used to create interactive and dynamic web pages. While Javascript is great, it has some limitations, including slow speeds when processing large amounts of data (common here for js debugging tips and tricks) and poor client side security, leaving the door open for potential malicious attacks on the code (i.e. 2014 Twitter fiasco). As more applications have been developed to be web native (i.e. Figma), these limitations have become more apparent.
Figure 1. WebAssembly overview (Source)
Wasm’s formal emergence in 2017 was the result of the collaboration between the world wide web (W3) consortium working together to realize the aspiration of “native” code in the browser. Predecessor attempts at this included technologies like asm.js and native client from Google. However, Wasm’s success was rooted in and it’s ability to work alongside Javascript, rather than trying to be a replacement for it—Wasm began as a way to run languages other than Javascript in the browser. Fundamentally, Wasm is a small byte-code language that is limited, and easy to implement, with an extensible entry point. How does this work? As a developer you:
Write the application in your preferred language.
Create a pre-compiled Wasm module.
Distribute the module—ideally, using a CDN for low latency.
What is the significance of being able to run other languages in the browser? I’ll refer to the scenario I described earlier.
With the ability to understand multiple languages, high-performance web applications can now be run in the browser seamlessly—AutoCAD, Figma, Canva, Adobe, Shopify—you name it. Multiplayer Last of Us. And, with a little extra work, the browser can now function as the personal ‘OS’, unlocking collaboration for remote workers, including our digital nomad in Bali.
Even more exciting are some of the WebAssembly use cases outside of the browser, which I’ll discuss in the next section.
Figure 2. Javascript vs. WebAssembly (Source)
What value does Wasm create for companies?
Interoperability. Security. Extensibility.
Wasm simplifies the software development and application compiling process. With cross-platform compatibility, developers can write once, and run anywhere. Just connect wasm and the platform and, as a developer, you are good to go—heavy, language specific re-writes are now extinct.
Figure 3. WebAssembly deployment (Source)
Given Wasm runs in a sandboxed environment, it cannot access the user’s system directly, lowering the risk of malicious code infecting the system. This makes it safer than other programming languages (C++, Java) which can access the system’s resources directly when writing applications.
For cloud or edge computing use cases, developers can now write code as individual functions that are executed in response to specific events or triggers. When applications are run out of the browser, companies can run Wasm programs on the edge, closer to the end customer for super-low latency. No more Bali buffering fiascos.
Wasm’s integrations with Redpanda and MotherDuck are examples that crystallize how Wasm works within the broader infrastructure stack.
Redpanda is a streaming data platform—a product that ingests, stores, and analyzes continuously streaming data in real-time. Redpanda has written about how it uses Wasm in its product, Redpanda Transforms. In this post, Alex Gallego, the CEO distills how Wasm helps Redpanda’s data ingestion at the server-side, detailing,
“Wasm empowers the engineers to transform Redpanda, by shipping computational guarantees (code) to the storage engine. Codifying business practices like GDPR compliance or custom on-disk encryption mechanics, with near native-level performance at runtime”
Gallego continues to expand on Wasm’s capabilities,
“WebAssembly will change server-side software permanently. Allowing injection of code inside Redpanda at strategic points fundamentally changes what the storage engine can do for you 0 while giving you isolation, high function density, granularity of execution, ~native performance, multi-tenant by design, all in your favorite programming language.”
MotherDuck, the company commercializing DuckDB, an in-process analytical database, uses Wasm to power analytics in the browser. Designed to be lightweight, DuckDB was purpose built to perform data analytics quickly, and most importantly, at the edge. In order to run in the browser, DuckDB partners with Wasm, furthering the project’s goal of a distributed, scalable, low cost SQL database. Andre Kohn and Dominik Moritz, co-authors of the Wasm-DuckDB piece claim,
“We further believe that the release of DuckDB-Wasm could be the first step towards a more universal data plane spanning across multiple layers including traditional database servers, clients, CDN workers and computation storage.”
Figure 4. Wasm ecosystem (Source)
These examples help illustrate the potential for Wasm to power a new paradigm of data infrastructure—one that is portable, distributed, and cost-efficient.
How have companies approached commercializing this technology?
At this point, it’s a fair question to posit, ‘Cool tech, but how does this make money?’ More informed readers might reference Hashicorp. Or for the pragmatist, Docker and Heroku, but regardless, a variety of companies are attempting to commercialize Wasm.
Some have focused on creating a platform-as-a-service to help facilitate Wasm (i.e. Fermyon, Cosmonic, and others). These companies, if following the Hashicorp/Terraform model, will focus on growing OS usage and sell a managed cloud version on top, equipped with additional features they charge for, like infrastructure provisioning.
Others have focused on building runtime engines, vying to be the specific engine for compiling Wasm code (i.e. Wasmer, Lunatic, and others). Incumbents with cloud edge capabilities like Cloudflare (i.e. Cloudflare Workers) and Fastly are working on the serverless deployment of code and Function-as-a-service (FaaS) capabilities. The goal for the majority of these companies will be increasing developer usage, with the eventual goal of selling proprietary features that augment the OS platform.
Despite all of Wasm’s advantages, it is universally considered difficult to use. The developer experience will have to improve for Wasm to become widely adopted. Dylibso could be the game changer for the industry, as it’s focused on improving the developer tooling for Wasm (with Extism and Modsurfer).
Figure 5. WebAssembly Landscape (Source)
What does the future hold?
The future of Wasm looks promising as a new paradigm of web development. This is specifically due to Wasm’s portability—portability enables ‘write once, run anywhere’. This in turn streamlines massive bottlenecks in development and improves software velocity. Further, it unlocks programs to become platforms—enabling more software that’s easier to customize, faster, and more secure.I am excited for what’s to come (and, importantly, more Last of Us).
Many thanks to Ian Livingstone, Steve Manuel, and Mischa Vaughn for their contributions to this piece.
Appendix
For future reading, please browse the well-articulated pieces about Wasm below: