Google’s confusing pitch for WebAssembly as a ‘new dawn of expanded functionality’

Google’s confusing pitch for WebAssembly as a ‘new dawn of expanded functionality’

Google’s Thomas Nattestad, product manager for V8 and WebAssembly (Wasm), has posted on the Chromium blog about the shift towards Wasm in web development.

According to Nattesdad, the portability and performance of Wasm means that “the web now has the necessary low level building blocks for a huge variety of new functionality to be built.” In a separate post he highlights some building blocks, picking out SQLite, a high performance local database engine that was formerly provided by the browser as Web SQL; FFMPEG on Wasm which enables video and audio processing; CanvasKit which implements the Skia rendering engine in the browser; and TensorFlow.js which is a library for machine learning.

The ability to deploy these large and powerful libraries as web applications, or parts of web applications, running with something approaching native performance, is remarkable in the increased capability it offers. This may be something of a mirage though, if it simply means that functionality which used to be built into the browser now has to be shipped independently with each application. Web SQL is an example, where SQLite used to be something every developer could use from JavaScript and is now replaced by a Wasm binary. According to Nattestad, Web SQL was “never adopted sufficiently across browsers” though it is a complex story.

FFMPEG on Wasm is another case where there is a standardized alternative, this being the WebCodecs API, but as Nattesdad notes, “it hasn’t been shipped across browsers yet.”

The confusing aspect of this post from the Chromium team is that it advocates both for Wasm as a way of short-circuiting the arduous and sometimes unpredictable standards process, and as a step along the journey towards standardised features in place of Wasm implementations. Naddesdad says that “by being battle-hardened in userland, browsers will have higher confidence and validation on what they should ship, dramatically simplifying the standards and implementation work.” What is the ideal future: a browser so capable that little Wasm is needed; or a browser that does little other than being a runtime for Wasm applications?

The trade-offs are considerable. The case for Wasm, Nattestad writes, is fast iteration sped, immediate cross-browser support, and what he says is “improved security compared to natively implemented APIs” – though in support of this he references Adobe Flash, which was a plugin, and not comparable to native code which ships as part of the browser itself.

The case against Wasm is increased size of web pages. “This is a large problem as lower bundle size is the most important thing for a good user experience,” says Nattestad. Another issue is that while Wasm is great for computation, by design it does not give access to the local file system or hardware. The browser on the other hand can access platform APIs.

There are also implications for the developer experience. In cases where reliable standard APIs built into the browser are available, that is easier than having to ship Wasm libraries; yet Wasm does offer an escape-route from the endless problems of cross-browser compatibility.

Is this a “new dawn of expanded functionality”, as Nattestad states, or a warning that web applications are likely to get more bloated as applications provide rich features at the expense of size and efficiency? In the end it is both. Whether or not that is a good thing is a matter for debate, but Web SQL is unlikely to return.