With all major browsers now supporting WebAssembly, it’s time to start thinking seriously about writing client-side applications for the web that can be compiled as WebAssembly.
Developers should consider WebAssembly for performance-demanding use cases such as gaming, music streaming, video editing, and CAD applications. Many web services have already taken the plunge, such as Google Earth. Figma, a collaborative drawing and diagramming application, turned to WebAssembly to reduce load times and execution speed, even when WebAssembly was relatively new.
How WebAssembly Works
WebAssembly, developed by the W3C, is in the words of its creators a “compilation target”. Developers don’t write WebAssembly directly; they write in the language of their choice, which is then compiled into WebAssembly bytecode. The bytecode is then executed on the client, usually in a web browser, where it is translated into native machine code and executed at high speed.
WebAssembly use cases
WebAssembly was designed with a number of performance-demanding, browser-based use cases in mind: gaming, music streaming, video editing, CAD, encryption, and image recognition, to name a few. name a few.
More generally, it is instructive to focus on these three areas when determining your particular use case for WebAssembly:
- Porting a desktop application to a web environment. Many tech demos for asm.js and WebAssembly fall into this category. WebAssembly can provide a substrate for more ambitious applications than a simple graphical interface presented via HTML. See the WebDSP and Windows 2000 in-browser demos for two examples.
WebAssembly language support
WebAssembly is not meant to be written directly. As the name suggests, it’s more like an assembly language, something the machine consumes, than a high-level, user-friendly programming language. WebAssembly is closer to the intermediate representation (IR) generated by the LLVM language compiler framework, than it is like C or Java.
So most scenarios for working with WebAssembly involve writing code in a high-level language and turning it into WebAssembly. This can be done in one of three basic ways:
- Direct compilation. The source is translated into WebAssembly using the language’s own compiler toolchain. Rust, C/C++, Kotlin/Native, and D now all have native ways to emit Wasm from compilers that support those languages.
- Third Party Tools. The language does not have native support for Wasm in its toolchain, but a third-party utility can be used to convert to Wasm. Java, Lua, and the .Net family of languages all have support like this.
- WebAssembly-based interpreter. Here, the language itself is not translated to WebAssembly; instead, an interpreter for the language, written in WebAssembly, executes code written in the language. This is the most cumbersome approach, as the interpreter can contain several megabytes of code, but it allows existing code written in the language to run virtually unchanged. Both Python (via PyScript, for example) and Ruby have translated interpreters in Wasm.
WebAssembly is still in its infancy. The WebAssembly toolchain and its implementation remain closer to proof of concept than production technology. That said, WebAssembly custodians aim to make WebAssembly more useful through a series of initiatives:
Garbage collection primitives
WebAssembly does not directly support languages that use reclaimed memory models. Languages such as Lua or Python can only be supported by limiting feature sets or by embedding the entire runtime environment as a WebAssembly executable. But work is underway to support reclaimed memory models, regardless of language or implementation.
Native threading support is common to languages such as Rust and C++. The lack of threading support in WebAssembly means that entire classes of WebAssembly-targeted software cannot be written in these languages. The proposal to add threading to WebAssembly uses the C++ threading model as one of its inspirations.
Mass storage and SIMD operations
Mass memory operations and SIMD (single instruction, multiple data) parallelism are essential for applications that shred stacks of data and need native CPU acceleration to avoid throttling, such as machine learning or scientific applications. Proposals are on the table to add these features to WebAssembly via new operators.
High-level language constructs
Many other features envisioned for WebAssembly correspond directly to high-level constructs in other languages.
- Exceptions can be emulated in WebAssembly, but cannot be implemented natively through WebAssembly’s instruction set. The proposed scheme for exceptions involves exception primitives compatible with the C++ exception model, which in turn could be used by other languages compiled into WebAssembly.
- Reference Types make it easier to pass objects used as references to the host environment. This would make it easier to implement garbage collection and a number of other high-level functions in WebAssembly.
- Tail callsa design pattern used in many languages.
- Functions returning multiple valuesfor example via tuples in Python or C#.
- Sign extension operators, a useful low-level mathematical operation. (LLVM also supports these.)
Debugging and profiling tools
Copyright © 2022 IDG Communications, Inc.