Wasm: What's the Big Deal?
A Short Explainer of Why Every Technical Blog Post Talks About WebAssembly
We are excited to feature a guest blog post at Software Snack Bites today with Matt Butcher, CEO & Co-Founder of Fermyon, which is building developer tools to make it easier to use WASM for cloud services (more below on why this is important). This post will focus on explaining what WASM is, why more teams are using it to build applications now, and how applying it server-side can have benefits vs the many obvious browser-side benefits we see today.
This post will cover 4 areas:
What is Wasm?
Why does it matter?
Common use cases for Wasm currently
Future of Wasm
What is Wasm?
WebAssembly (abbreviated “Wasm”) began its life as a way to run languages other than JavaScript in the web browser. It has outgrown its original mandate, and in all the best ways.
On a technical level WebAssembly is simply a definition of a bytecode format together with instructions on how to execute that format. The idea is that compilers for various languages can all compile to this same binary format, which can then be executed on any runtime that supports the specification. It is fair to think of this as the new “write once, run anywhere.”
For example, C, Rust, and Go (three very different languages) can all be compiled to WebAssembly. And once compiled to WebAssembly, the binaries can be executed by any WebAssembly runtime.
WebAssembly rapidly gained traction among browser makers. Already, all the major web browsers support WebAssembly. But over the last few years, the potential of WebAssembly has piqued interest well beyond the browser market. Now we’re seeing this technology show up in a variety of places.
Why Does it Matter?
What makes WebAssembly special is its set of runtime characteristics. Given the description above, it would be fair to compare WebAssembly to Java or to .NET. After all, both of these language ecosystems define an intermediate bytecode format that can be executed by a common runtime (the JRE or the CLR, respectively). But WebAssembly has a few key differences that make it stand out for new use cases.
WebAssembly was originally built for the browser, which means it was constructed with a certain set of requirements:
Security: A WebAssembly binary must be restricted to a sandbox, and cannot access system resources it is not explicitly given access to.
Platform Neutrality: A WebAssembly binary must (like JS, CSS, HTML, etc.) run on any OS and any architecture.
Startup Speed: Users don’t wait for web pages to load, so WebAssembly must be quick to start.
Execution Speed: One of WebAssembly’s key value propositions is that certain computations that might take a long time in a language like JavaScript should be able to execute more quickly in, say, Rust compiled to WebAssembly
Ease of Integration: Another key design goal of WebAssembly is its ability to integrate with its environment. In the initial case, this means making it easy to expose JavaScript functions inside of WebAssembly as well as exporting WebAssembly functions to be used by JavaScript
Reading through the list above, it becomes evident that while all of these design goals are necessary for the browser use case, none of them tie WebAssembly to the browser. In other words, it should be (and in fact is) possible to take a WebAssembly runtime and drop it into other environments while still preserving these features.
This is exactly what we are seeing occur now.
Common Use Cases of Wasm
There are three broad use cases where WebAssembly is growing:
In-browser web applications
Plugins and extensions for applications
Cloud and edge computing services
The first case is web applications. WebAssembly did not immediately catch on in the browser world. A few companies have famously ported major features to WebAssembly, with Figma and Adobe leading the way. And there are a few web application frameworks that feature WebAssembly (notably the Blazor .NET framework). But only a miniscule portion of the sites on the web used WebAssembly in the past few years.
But things seem to be changing now. Databases (including sqlite and PostgreSQL) can be compiled to WebAssembly and run in-browser. Browser frameworks are getting more WebAssembly-friendly. And with a wealth of new languages supporting WebAssembly, we’re seeing excitement build about running Python, Ruby, Go, .NET, Rust, C, and many other languages inside of the browser in a safe way.
The second case is plugins and extensions. Because WebAssembly is supported by a broad range of languages and is easy to integrate with local APIs and functions, WebAssembly is an attractive technology for supporting plugins. The Envoy proxy, the Microsoft Flight Simulator, and SingleStore’s new WebAssembly-based User Defined Functions (UDFs) are examples of this. In each case, the product supplies the WebAssembly runtime together with a list of APIs that the WebAssembly code can import. Developers can then write code in the language of their choice. Utilizing the supplied APIs, they can extend the initial application with their own custom logic, and then upload and run the WebAssembly binary within the context of the application. This second model is catching on with blockchain computing. And the startup Suborbital is building a general-purpose technology to support this plugin model.
The third case is cloud services. For the edge (Fastly, Cloudflare) and public clouds (AWS, Azure, Google), and on-prem, compute services expose managed facilities for running applications. In the past, we have thought of these in terms of virtual machines and containers. Again drawing on the design principles that made it good for the browser, WebAssembly is a good fit for the cloud. Security, speed, extensibility, and platform neutrality are each desirable features of a cloud computing technology. At Fermyon, we refer to WebAssembly-in-the-cloud as the next wave of cloud computing. Established companies like Fastly, Docker, and VMware are recognizing this potential as are startups like Fermyon, Lunatic, and Cosmonic.
At Fermyon, we believe that the cloud case is the stand-out. In a world of costly and overly complex cloud systems, WebAssembly stands out as a technology that can drive cost down, improve performance, and meet developers where they are. Fermyon Spin is our open source developer tool for rapidly building cloud applications using a Functions-as-a-Service (FaaS) style like AWS Lambda, and the Fermyon Platform is an open source host-it-yourself platform for running these applications on the cloud of your choice.
Future of Wasm
What is in store for WebAssembly over the next few years? Above, I outlined three use cases, and I believe we will see all three of those continue to blossom. Thanks to the emerging Component Model specification (standardized, like all WebAssembly technology, under the auspices of W3), the three are not likely to form into isolated silos. The Component Model specification will make it possible for individual WebAssembly binaries to describe what they can do (what functions they export) as well as what they need (what functions they import) such that the same compiled binaries can be used in the browser, in plugins, and on the cloud. We will see something like an NPM-style repository of WebAssembly libraries. But it won’t matter what language each library was written – they will all simply work together via WebAssembly.
In the near future, we will also see the steady march of language support continue forward. Python and Ruby are both nearing production for their WebAssembly support. We’ve seen .NET make leaps and bounds in their own support. The Swift community has already built a remarkable WebAssembly compiler that is improving by the day. Kotlin and Java are both coming along as well. Within a year, I expect that more than 15 of the top 20 programming languages will be executable inside of a WebAssembly runtime. (We keep tabs on the top programming languages in the Fermyon Language Support Matrix.)
Finally, there are a variety of other WebAssembly standards that are moving along. These include threading support, network sockets, and built-in memory management (a boon to compiler developers). As each of these reach maturity, we will see correlating boosts to WebAssembly usage around all three of the use cases I elaborated above.
Conclusion
It may have started as a web browser technology, but WebAssembly has caught on in several places. As a binary format that can be executed on a wide variety of platforms, operating systems, and architectures, WebAssembly is poised to become a major technology over the next few years. In addition to the browser, WebAssembly is gaining traction as a plugin technology and as a cloud compute platform.
As several key specifications mature, WebAssembly will only increase in adoption. And once the Component Model specification becomes widely adopted, the same WebAssembly libraries can be used in any standards-compliant runtime. Developers will no longer need language-specific libraries to get the job done, and countless hours will no longer be spent maintaining parallel feature sets in various language-specific libraries.
What I’ve enjoyed reading/listening to this week:
Simple protocols to follow to lead a healthier life
Discovered the Founders Podcast that does summaries of biographies and pulling out interesting facts/lessons learned. Strongly recommend!
Very cool story from Mitchell Hashimoto, Co-Founder of Hashicorp talking about the evolution of Terraform (Hashicorp’s biggest product) and how it has been 8 years from first line of code to where it is today. They even considered shutting down Terraform in 2015 as user traction wasn’t growing. Moral of the story for founders and OSS maintainers: infrastructure is hard and takes a long time to work! However, by closely working alongside users, that will compound leading to exponential growth in the future.
