The Risks of WebAssembly

FERMYON.COM

WebAssembly is an emerging and exciting technology, and as a result most of the content we read (and write) about WebAssembly is filled with optimism around what can be achieved now, and will be possible in the future. However, sometimes we have to take a step back and consider the negatives, or as this blog post puts it, the risks.

This blog post does a great job of outlining some of the challenges that Fermyon, and the wider community, are currently facing with WebAssembly. For example, the slow-moving nature of standards development, where significant proposals like garbage collection and threading are making painfully slow progress. They also highlight the risk of fragmentation, something which they are starting to observe.

AssemblyScript - Standards Objections

ASSEMBLYSCRIPT.ORG

Somewhat continuing the theme …

AssemblyScript is a TypeScript-like language that was developed specifically for WebAssembly. As a result it is quite lightweight, with very little between the language and the runtime. It gives the AssemblyScript team a unique insight on the WebAssembly standards as they evolve.

This blog post, which is quite detailed and references many other discussions, highlights the challenges the AssemblyScript team are experiencing while participating in the WebAssembly standards process, most notably WASI and the component model specification.

The general sentiment expressed throughout this post is that the original goals of WebAssembly are being compromised by the newer WASI standard, which appears to have somewhat competing goals. As a result, WebAssembly running within the browser (its original home) will suffer. There are also a number of instances where the AssemblyScript team indicate that the standards processes themselves are not being supportive of the debates that need to be had in order to create a balanced specification.

For a more brief opinion, Max Graey, one of the AssemblyScript team members writes on Hacker News:

The main problem of WASI in my opinion is that it’s based on a standard which is 30 years old. And yes, the idea was cool, to let you run even C without having to rewrite libc. But the reality is that we can’t do this now and it’s still a big question whether we can in the near future. Besides, C is probably the only one that needs such a low level api, but everyone has to suffer because of it, essentially reinventing libc based on WASI with their own language runtime on top of it. This is simply a waste of binary space.

There is clearly a lot going on here, and I honestly haven’t had the time to fully immerse myself in the detail. However, I do think that AssemblyScript holds a very important place in our ecosystem, and the views of that team, and the needs of this language, are very important.

Running JavaScript in WebAssembly with WasmEdge

SECONDSTATE.IO

JavaScript is a dynamically typed language that requires a garbage collector, as a result it isn’t a natural fit for compiling to WebAssembly. However, JavaScript already runs within the browser, so why does this matter? When using WebAssembly as a non-browser runtime of course!

JavaScript is a very popular language, and as a result, if you’ve built an edge platform or plugin system that uses WebAssembly, you’ll likely want to offer JavaScript support. This blog posts details how QuickJS, a lightweight JavaScript runtime, can be compiled to WebAssembly allowing JavaScript code to run within an interpreter.

Introducing support for WebAssembly at the Edge

VERCEL.COM

Vercel is the platform for frontend developers, providing a suite of services for development and deployment of web applications. As part of their suite of services they provide edge functions. This blog post announces WebAssembly support 👍