A Pragmatic WebAssembly FAQ
WebAssembly is intuitive to grasp but difficult to assess, even for experienced technologists. This FAQ breaks down one question — “What is WebAssembly” — into its immediate followups to help you understand if it’s a technology you should be following.
This is not a technical FAQ, but scroll to the bottom for more technical links.
What is WebAssembly?
Why is WebAssembly important?
While WebAssembly was created by web experts and adding an additional execution environment to web browsers is monumental, its implications reach far beyond the browser.
The web is a distinctly hostile environment. Any web feature must accommodate unique security and privacy concerns, must not impact performance on a wide range of resource-limited clients, and must be backwards compatible with every site built over the last twenty-five years. This adversity affects how ideas evolve and forces considerations that could be ignored otherwise.
The web’s unique problems were not insurmountable. Companies offered solutions since the days of Java applets, all the way to Adobe Flash and Microsoft ActiveX. The crux is that these were proprietary. They only existed as opt-in plugins. The web is built on open standards and to become part of a web browser, a committee must agree on a single technology and its implementation.
What you get when you need to please everyone is a minuscule implementation that does the bare minimum. While unintuitive, this is why WebAssembly is important. The bare minimum is a foundation of 25 years of web security, performance, and distributed application lessons. The WebAssembly MVP is difficult-to-use but it has a rock solid foundation. What little it does now, it does well and can only improve.
If I don’t target the web, should I care about WebAssembly?
WebAssembly has a large fan base among systems programmers and is gaining traction in every community, not just web developers. Despite the potential, WebAssembly does come with risks. The developer experience is poor and developer tooling is sparse and fragmented. Developers who can compile and execute WebAssembly at all are uncommon and architects who understand how WebAssembly fits in to a bigger picture are even more rare. Companies like Fastly, Figma, and CloudFlare are taking advantage of WebAssembly but have had their share of headaches along the way. WebAssembly is squarely in the Early Adopter or even the Innovator phase of the adoption curve.
If you generally wait until a technology has proven itself before using it, take comfort that you will benefit from WebAssembly via your tooling before you need to work with it directly. Similarly, if you are evaluating services and vendors, their stance on WebAssembly is a good indicator of how much they are investing in the future.
My engineers tell me WebAssembly is not ready, what’s the deal?
We’ve seen most of the confusion stem from two specific topics: WASI and WebAssembly’s data types. The former commonly manifests as comments like “WebAssembly can’t do anything yet” and the latter as “WebAssembly is only for math-heavy computation.”
The WebAssembly System Interface, or WASI, is a project to define a consistent, cross-platform interface to operating system functionality. WebAssembly can only compute by default. It can’t read files, make network requests, or “do anything yet.” WASI gives WebAssembly native-like functionality. WASI is a work in progress but even without WASI, a host environment can still expose arbitrary native functionality to WebAssembly modules. WASI is a community standard. It is not a gating factor to real-world WebAssembly usage.