A New Chapter for WebAssembly?
By Caitlin Lohrenz and Johanan “Joj” Ottensooser
It is not new. It is not ChatGPT. But these days, we’ve been thinking a lot about WebAssembly (WASM), a low-level binary instruction format originally designed to make web applications faster. Why are we so excited? We believe the technology has reached an inflection point that will determine its success beyond current use cases in the browser, and now has the potential to completely change how we do distributed computing, which is worth the hype if done right.
On the other hand, there is a huge question mark around widespread adoption – will the ecosystem mature fast enough? Will the right champion(s) emerge? Will people change their existing workflows to leverage WebAssembly? Just like with any startup, reaching escape velocity requires both a technological and a go-to-market advantage. In the case of WebAssembly, we will see if the latter emerges.
Below, we explore the state of WebAssembly today, the gap it could fill for the next era of application development, and the opportunities we see in the space today.
The Status Quo: WebAssembly in the Browser
Today, we interact with WebAssembly all the time—probably without realizing. If you have ever designed a model in SketchUp, collaborated with a colleague on wireframes in Figma, or played any one of Unity’s online games, then you have benefited from WebAssembly.
In the simplest terms, WebAssembly moves compute to your computer (i.e., directly within your browser) as opposed to server-side, so web applications are lightning quick. Long gone are the days where third-party plugins, such as Adobe Flash, were required to view or interact with large amounts of data within a web application.
Leveraging WebAssembly, developers can write applications in highly performant computing languages, such as C/C++ or Rust, compile that code into a standard WebAssembly binary format, and execute directly in browser at near-native speed. This enables data processing directly within the browser with little to zero latency, even for complex tasks such as video editing.
WebAssembly is already powering applications worth billions of dollars today and given its performance advantages we expect it to continue to grow. That in-browser potential, however, is likely dwarfed by the size of the broader cloud and edge computing market, which we believe WebAssembly could meaningfully disrupt (IDC’s Worldwide Public Cloud Infrastructure as a Service Forecast, August 2022).
WebAssembly Outside the Browser: A New Container?
We believe leveraging WebAssembly outside the browser has the potential to transform distributed application development — both in cloud and edge environments.
Today, distributed computing relies heavily on the use of containers and container images, which were developed to solve some of the “clunkiness” introduced by their Virtual Machine (VMs) predecessors. Together, these two components make it possible to run isolated processes without virtualizing the underlying hardware, thus making application deployment much faster and highly scalable.
However, certain modern application requirements are starting to expose the limitations of containers, potentially paving the way for the increased usage of WebAssembly both instead of, and alongside traditional containers. A few places where we think WebAssembly has an advantage are:
- Start Up Speed: Because WebAssembly was built for the browser initially, it is both extremely lightweight and fast to stand up. It is possible to spin up and shut down WebAssembly modules almost instantly, creating both performance and cost benefits. This level of spin up performance might not be necessary in all situations, but where you need something flexible to execute all or parts of an application quickly (think IoT), WebAssembly can fill this need. One area where this is particularly beneficial is with serverless architectures, where each resource follows a spin up/spin down cycle. Additionally, this start up speed advantage could lead to meaningful cloud cost savings over time.
- Portability: Containers are still hardware or platform dependent, meaning different images are required depending on the architecture. WebAssembly, however, is portable over different hardware and operating systems. While this might not make a big difference in the case of a datacenter, we see huge implications for edge computing and IoT.
- Security: Security was a design priority from the beginning for WebAssembly. WebAssembly runs in a “sandbox”, which means each module runs in a separate environment separated from the host runtime. Whilst WebAssembly is not alone in sandboxing, its memory isolation, filesystem isolation, and network isolation make its execution model less prone to vulnerabilities.
- Complexity: Containers across large scale deployments often become hard to maintain over time. Engineering resources are frequently leveraged on application maintenance and deployment instead of on building new products.
These qualities make WebAssembly an attractive compute unit for distributed applications or workloads — not dissimilar to how containers are treated today. While WebAssembly modules might not always be a direct substitute for containers, we are excited about how they will operate together to build faster, more dynamic, distributed systems.
Framing the Opportunity for WebAssembly Today
We are focused on three interesting buckets of opportunity for leveraging WebAssembly:
- Tools that make use of WebAssembly as it exists today. We’re seeing companies dip their toes into virtualization, emulation and even basic orchestration with WebAssembly, especially in situations where performance is not a key factor. For example, Prospective, the company behind the open-source project Perspective, is leveraging WebAssembly as a core part of their platform aiming to transform the way users approach large-scale data exploration and visualization. We also believe there is still significant progress to be made on improving the ergonomics of the developer experience when using WebAssembly. This could include things like allowing developers to write in languages they are more familiar with than JavaScript.
- Tools that will require WebAssembly to improve its performance. As WebAssembly improves, we expect it to be able to take on some use cases that were previously performed by other virtualization options, such as VMs and hypervisors, or containers and orchestration tools. This would enable developers to trivially abstract both the operating system of the device they are running their software on and the hardware itself. This could mean that the same application could run as written on an x86 computer, an M2 laptop, an ARM phone, or even a PowerPC workstation.
- Tools that are designed explicitly for WebAssembly. It is also possible that existing computing patterns, (i.e., the way we currently design distributed systems) change to take advantages of the strengths of WebAssembly completely. It might be hard to see what these use cases look like today, but we are excited to work with entrepreneurs who are thinking about these. What use cases could uniquely benefit from short-lived systems? What types of hardware could share computing resources to expand the use of edge computing? This could include new use cases that shift the line between front and back-end development. Whereas before all compute-heavy business logic was handled by the back-end, with WebAssembly users can write back-end functions in Python or Rust, and then run the same business logic on the front end, removing the risk of drift or inconsistency between front and back-end development.
While we remain excited about WebAssembly, reaching mainstream adoption will be a challenge. Existing container technologies, such as Kubernetes and Docker, certainly have limitations and drawbacks, but there is a huge ecosystem around these technologies — developers, companies, experts, contributors — that we believe drastically reduces the barriers to implementation and makes them the de facto standard. Similarly, we believe these non-technical elements will play a more important role in WebAssembly’s future success than the technology itself. We will continue to watch for evangelists to emerge and developers to rally around standard best practices.
We would love to connect with you if you are…
- Exploring building a company in the WebAssembly space
- Actively contributing to the WebAssembly ecosystem
- Or deeply skeptical of WebAssembly’s role in the broader development ecosystem