Today we’re happy to announce, in tandem with Firefox and Edge, a WebAssembly Browser Preview. WebAssembly or wasm is a new runtime and compilation target for the web, designed by collaborators from Google, Mozilla, Microsoft, Apple, and the W3C WebAssembly Community Group.

2018-08-16: WebAssembly Attacks

WebAssembly is a format that allows code written in assembly-like instructions to be run from JavaScript. It has recently been implemented in all 4 major browsers. We reviewed each browser’s WebAssembly implementation and found 3 vulnerabilities. This blog post gives an overview of the features and attack surface of WebAssembly, as well as the vulnerabilities we found.

2023-01-19: While I still think node.js is a dumb joke, this makes a good point for using wasm instead of containers

The following are a few of the reasons WASM is worth keeping an eye on.

1. It’s Getting Faster
   Speed is a feature, and those behind the WASM specification have been hard at work. A little over 3 years ago we spoke to some of the core dev team, and their estimation was that WASM came with approximately a 20% performance hit versus native code. They speculated that within 2 years that difference could be erased, or at least made negligible enough to not matter. Today, depending on platform and workload, that has proven to be the case; one provider even claimed recently to run faster within WASM than natively. The performance limitations, therefore, that have held WASM back in the past are largely subsiding, making it viable for more and more workloads.
2. It’s Quick
   If WASM has been compelled to work on its overall performance, there’s no such need with respect to its latency. Even from cold start situations, WASM’s latency is measured in milliseconds, not actual seconds as is typical with other application platforms from containers to function-as-a-service providers. This makes it highly suitable for workloads that are latency-sensitive, which is more and more workloads – and certainly the event-based workloads that are becoming more common within the enterprise.
3. It’s (Relatively) Secure
   Granting that no software is immune to vulnerabilities, WASM is nevertheless distinguished in this area. Designed from day one to be secure enough to run executables within the context of an individual’s browser, it is based on sandbox principles, with no access to or from the outside by definition. At a minimum, the historical priority placed on security has been higher than other platforms, a fact likely to be appreciated by security-sensitive enterprise buyers.
4. It’s Lightweight
   Relative to something like V8 isolates, WASM executables are sizable. But just as containers were much lighter weight than the virtual machines they supplanted, so too is WASM dramatically lighter weight than containers. This means that, properly orchestrated (a subject we’ll come back to), WASM deployments can be fantastically dense relative to their container based peers; one provider reports 20X-30X more WASM sandboxes than Kubernetes containers, for example, on a given piece of hardware. Similarly, Cloudflare has talked about their usage of Isolates to achieve the same goal.

   This density is, in part, why the popular assertion that a growth in WASM deployments will enable something of a renaissance of PaaS platforms seems correct. The unit economics of running platforms – potentially more safely – at dramatically higher densities than container-based alternatives make WASM-based PaaS platforms more viable not only technically but economically as well. Both in terms of their overall end user pricing, but also potentially making free or lower cost tiers possible that have previously been deemed cost prohibitive by vendors such as Heroku.

5. The Language Support is Improving
   For enterprises used to working with container-based platforms, or virtual machines before that, language limitations are non-existent. Whatever the language and runtime, a given application is wrapped in a container and then run on platforms like Kubernetes alongside hundreds or thousands of other workloads, covering a multitude of languages. But as Fermyon’s language support page indicates, WASM’s support for various programming languages varies, and widely. But this is unlikely to be a fatal flaw for WASM-based providers. First, because the support for new languages is improving, and at an accelerating pace as more attention is focused on the technology. Second, because the set of core languages supported already (C/C++. C#, Go, Kotlin, Rust, Swift etc) cover a large number of potential workloads. And lastly because abstract models like PaaS have always imposed such constraints, and if anything that’s likely to become more common rather than less as more and more abstract models emerge.