The AssemblyScript project has declared WASI (The WebAssembly System Interface) and the W3C (World Wide Web Consortium) support for it to be “harmful to open standards in general and the WebAssembly specification in particular.”

Last month the project stated that it had “removed support for WASI” and this week posted details of its objections. The AssemblyScript team said that “collaboration towards eventual resolution is no longer deemed possible” and that “WASI and the WASI group make it almost impossible for other participants to pursue efforts aligned with WebAssembly’s goals.”

WebAssembly is a low-level language that compiles to a binary format that runs at near-native speed in web browsers. By contrast, WASI, from its own project description, is “designed to be independent of browsers, so it doesn’t depend on Web APIs or JS, and isn’t limited by the need to be compatible with JS.” WASI works with Wasmtime, a standalone runtime for WebAssembly, or with limited features in a browser via a polyfill. A polyfill is code to add APIs that browsers do not support natively.

A key goal of Wasmtime and therefore WASI is to provide a secure, sandboxed runtime for applications running outside the browser. The idea of a secure desktop runtime is not new, with other examples including Java and early versions of the Windows runtime for Windows 8. An inherent problem is that the access to native features which desktop users expect tends also to undermine the security of the sandbox. WASI aims to provide a standard and secure API for system capabilities including files and networking.

AssemblyScript is a project to compile a variant of TypeScript to WebAssembly. “While not all of TypeScript can be supported, its close relation to JavaScript makes it a familiar choice for developers who are already used to writing code for the Web,” the docs explain.

When developers first raised the idea of compiling TypeScript to WebAssembly, back in 2016, it was dismissed with comments like “JS engines already turn JS code into assembly at runtime, and can do a very good job of it because they have a complete runtime profile. There’s really no obvious upfront gains to be had from translating a working JS program into WASM.”  

Since then though, WebAssembly has become more important, not least to Microsoft’s Blazor framework which runs .NET code in the browser by this route. The AssemblyScript docs state that good use cases for the project are “computation-heavy logic like image manipulation, hot game logic, specialized algorithms, emulators, compilers and the likes.”

Those docs also point to WASI as a way of running AssemblyScript outside the browser, but the team now takes the view that “WASI does not integrate with the existing Web platform but fundamentally competes with it.” One of the concerns is that WASI does not just provide APIs that are missing in the browser, but also provides alternative APIs for the same features.

It also appears that there are personal disagreements, and the problem seems to be as much a breakdown in communication as a technical argument. There is reference to this issue raised last year, where a discussion was closed for non-technical reasons, though WASI chair Lin Clark, a senior principal engineer at Fastly, also asserted that “the concern that WASI will harm the web is not well supported.”

The AssemblyScript project has not entirely abandoned WASI, providing a shim that “offers almost identical functionality to the former WASI support that was included with the AssemblyScript compiler.”