WebAssembly from the Ground Up

@wasmgroundup.com

266 Followers 191 Following

A book about WebAssembly by @marianoguerra.org and @dubroy.com — learn Wasm by building a simple compiler in JavaScript. https://wasmgroundup.com/

import jz from 'jz' // 3 lines of JS → 120 bytes of WASM, compiles in <1ms const { exports } = await WebAssembly.instantiate(jz(` let { sin, PI } = Math export let sine = (out, freq, t) => { for (let i = 0; i < out.length; i++) out[i] = sin((t + i) * freq * PI * 2 / 44100) } `)) // Real-time audio at native speed, zero GC pauses exports.sine(audioBuffer, 440, sampleOffset)
Ahoy! Hope your February has been swell. Here in southern Germany, it's been a relatively snowy winter…but it's finally starting to feel like spring. First and foremost, we wanted to let you know that we published a new blog post last week, A WebAssembly interpreter (Part 2). In Part 1, we created a simple Wasm interpreter from scratch, but it was only able to evaluate expressions consisting of literals. In the latest post, we add support for local and global variables. Give it a look! And here are your Wasm tidbits for February: • "WebCC is a lightweight, zero-dependency C++ toolchain and framework for building WebAssembly applications. It provides a direct, high-performance bridge between C++ and HTML5 APIs." And then there's Coi, "a modern, component-based language for building reactive web apps", which is built on WebCC. • Marimo is an open-source reactive Python notebook; like Jupyter, but better in many ways (no hidden state, stored as pure Python files, …). And it also supports WebAssembly notebooks, powered by Pyodide; in other words, Wasm notebooks execute entirely in the browser, without a backend executing Python. • Along the same lines: Pandoc for the People is a fully-featured GUI interface for Pandoc (probably the most-used Haskell program ever). It lets you run any kind of conversion that pandoc supports, without the documents ever leaving your computer. It's based on the recent Pandoc 3.9 release, which supports Wasm via the GHC wasm backend.
import * as w from "@wasmgroundup/emit"; const mod = w.module([ w.typesec([w.functype([w.valtype.i32, w.valtype.i32], [w.valtype.i32])]), w.funcsec([w.typeidx(0)]), w.exportsec([w.export_("add", w.exportdesc.func(w.funcidx(0)))]), w.codesec([ w.code( w.func( [], w.expr([ [w.instr.local.get, ...w.i32(0)], [w.instr.local.get, ...w.i32(1)], w.instr.i32.add, ]), ), ), ]), ]); const { instance } = await WebAssembly.instantiate(w.flatten(mod)); const { add } = instance.exports as { add: (a: number, b: number) => number }; console.log(add(1, 2)); // 3
Hey y'all — Some of you might be on your way to FOSDEM, or already there; if so, have fun! Looks like there won't be a WebAssembly devroom this year, but there are a few Wasm talks on the schedule. Anyways, here are your Wasm tidbits for January: • eBPF.party is a set of hands-on exercises to learn about eBPF. It features a browser-based live feedback editor for C code, powered by TCC (Tiny C Compiler) compiled to Wasm. • Meet Whamm: The WebAssembly Instrumentation Framework. • Building docfind: Fast Client-Side Search with Rust and WebAssembly has some details on how the VS Code team built a client-side search engine for their documentation. • The 2025 Web Almanac from the Http Archive has some interesting details about how Wasm is being used on the web: "We periodically crawl the top sites on the web and record detailed information about fetched resources, used web platform APIs and features, and execution traces of each page…then crunch and analyze this data to identify trends."
Wasm tidbits • All the videos from the WebAssembly Workshop at ICFP/SPLASH '25 are up on YouTube. There are a bunch of interesting ones, but we particularly enjoyed Oscar Spencer's Wasm GC and the Future of High-Level Language Compilation. • The Feature Status page on webassembly.org has been updated to include a bunch of new engines and tools, including Wizard, wazero, and Binaryen. • It's not directly related to WebAssembly, but we've been following Matt Godbolt's Advent of Compiler Optimizations, and it's been great so far. It's a nice way to learn a bit more about x86 and ARM assembly, and about the various optimizations that C++ compilers do. You can follow it on his blog or on YouTube. • Andy Wingo: "If anyone has never worked on a baseline compiler before, they are a really funny space; my first experience with Firefox's Wasm baseline compiler was an eye-opener for me." Firefox's low-latency WebAssembly compiler (2020). • For a deeper look at strategies for baseline compilation, see Ben Titzer's Whose baseline compiler is it anyway?. "We demystify single-pass compilers for Wasm, explaining their internal algorithms and tradeoffs, as well as providing a detailed empirical study of those employed in production." • We recently met some folks from CedarDB (the commercial version of the Umbra database system), who told us about how they use Wasm for user-defined operators. The details can be found in Moritz Sichert's PhD dissertation, Efficient and Safe Integration of User-Defined Operators into Modern Database Systems.
Excerpt from the V8 Sandbox - Bytecode Verification doc, reading: "The bytecode verifier needs to ensure that the execution of verified bytecode does not lead to out-of-sandbox corruption, specifically stack corruption. As the bytecode is fairly simple, this reduces down to a few basic properties that must be verified: Spatial memory safety: stores (and potentially loads) to/from the stack stay inside the stack frame and so do not corrupt stack memory Control-flow Integrity (CFI): jumps within the bytecode land at a valid instruction (otherwise, we might execute arbitrary instruction and so the first property could not be guaranteed) No unsafe functions: the bytecode should not call unsafe runtime or native functions These properties are verifiable in linear time (constant per bytecode) with a relatively simple validator."
I'm a few chapters in, and the book truly exemplifies iterative learning 'from the ground up'. It starts with atomic units and the simplest thing that could possibly work, but then each chapter builds on the previous, while not jumping over any gaps. As an author, I appreciate how much thought went into creating that experience, but as a reader, it's just a smooth ride. Thanks Mariano Guerra and Patrick Dubroy for such an excellent book. I highly recommend it!
// im*:vec(import) export function importsec(ims) { return section(SECTION_ID_IMPORT, vec(ims)); } // mod:name nm:name d:importdesc export function import_(mod, nm, d) { return [name(mod), name(nm), d]; } export const importdesc = { // x:typeidx func(x) { return [0x00, typeidx(x)]; }, };
A screenshot of the Hacker News front page. Post #5 is circled in bright pink — the title is "WebAssembly from the Ground Up", and it has 105 point and 19 comments.
A pixel art image with a pink background showing multiple circular muffin sprites and one small purple character sprite, rendered in a retro video game style. The muffins are beige, with light-colored frosting on top and a red cherry. The player looks like a mouse with oversized eyes and ears.
Abstract WebAssembly (Wasm) has been extended to support features such as garbage collection, references, exceptions, and tail calls that facilitate compilation of managed languages. In this paper, we capture a snapshot of the performance of languages that use these new capabilities from two perspectives. First, we present a language-by-language performance comparison of six managed language implementations on Wasm to the performance to their native implementations. Second, we focus on the implementation of the Bigloo Scheme compiler and explore the impact of different choices for compiling specific aspects of the language. Our findings suggest that Wasm has become a promising compilation target for most managed languages, but that its performance still falls short of that achieved by native code. Our results also show that the quality of the Wasm implementations vary, with the best ones being, on average, about 1.4× slower than the native backend and the worst ones seeing average slowdowns of more than 8× with some tests even failing to execute correctly. Disclaimer ☞ This study contains no novelty regarding compilation or, more generally, implementation techniques. Its purpose is to provide information to language communities about the state of existing Wasm backends. Specifically, it offers information that sets some basic performance expectations and it offers some experience with the performance of several specific compilation technique choices in the context of the Bigloo Scheme compiler.
But how do we actually use WebGPU? Our renderer is written in C++. We compile this C++ code to WebAssembly (Wasm) using Emscripten, in order to use it in the main Figma application. But we also compile our C++ renderer code into a native x64/arm64 application used for server-side rendering, as well as testing and debugging. So we needed a way to write code using the WebGPU C/C++ API and have it work in both cases, with minimal per-platform branching. For Wasm, we decided to use Emscripten’s built-in WebGPU bindings support. This means that C++ WebGPU calls ultimately end up using the WebGPU browser API in JavaScript, even though our code is written in C++. We also had to write some of our own custom C++/JS bindings in cases where these built-in bindings weren’t performant enough.
First page of an academic paper entitled "AnyBlox: A Framework for Self-Decoding Datasets", by Mateusz Gienieczko and four other authors (including Thomas Neumann), all from TU Munich. The abstract reads: "Research advancements in storage formats continuously produce more efficient encodings and better compression rates. Despite this, new formats are not adopted due to high implementation cost and existing formats cannot evolve because they need to maintain compatibility across systems. Can this problem be solved by introducing a new abstraction? We answer affirmatively with AnyBlox, a frame work for reading arbitrary datasets using lightweight WebAssembly decoders bundled with the data. By decoupling decoders from both systems and file format specifications, AnyBlox allows transparent format evolution, instance-optimized encodings, and enables mainstream adoption of research advancements. It integrates seamlessly with modern systems like DuckDB, Spark, and Umbra, while delivering solid performance and security guarantees." On the right, a colourful diagram is captioned: "The N ×M problem: In the past (left) every system controlled its data and internal format. Today (right) data is outside of systems’ control. No system supports all formats and each system has specialized glue code for each format."
Fast execution of JavaScript relies heavily on speculative optimizations. That is, JIT-compilers make assumptions when generating machine code based on feedback that was collected during earlier executions. For example, given the expression a + b, the compiler can generate machine code for an integer addition if past feedback indicates that a and b are integers (and not strings, floating point numbers, or other objects). Without making such assumptions, the compiler would have to emit generic code that handles the full behavior of the + operator in JavaScript, which is complex and thus much slower. If the program later behaves differently and thus violates assumptions made when generating the optimized code, V8 performs a deoptimization (or deopt, for short). That means throwing away the optimized code and continuing execution in unoptimized code (and collecting more feedback to possibly tier-up again later). In contrast to JavaScript, fast execution of WebAssembly hasn’t required speculative optimizations and deopts. One reason is that WebAssembly programs can already be optimized quite well because more information is statically available as e.g., functions, instructions, and variables are all statically typed. Another reason is that WebAssembly binaries are often compiled from C, C++, or Rust. These source languages are also more amenable to static analysis than JavaScript, and thus toolchains such as Emscripten (based on LLVM) or Binaryen can already optimize the program ahead-of-time. This results in fairly well-optimized binaries, at least when targeting WebAssembly 1.0, which launched in 2017.
After almost three years since the initial design document and hundreds of CLs in the meantime, the V8 Sandbox — a lightweight, in-process sandbox for V8 — has now progressed to the point where it is no longer considered an experimental security feature. Starting today, the V8 Sandbox is included in Chrome's Vulnerability Reward Program (VRP). While there are still a number of issues to resolve before it becomes a strong security boundary, the VRP inclusion is an important step in that direction. Chrome 123 could therefore be considered to be a sort of "beta" release for the sandbox. This blog post uses this opportunity to discuss the motivation behind the sandbox, show how it prevents memory corruption in V8 from spreading within the host process, and ultimately explain why it is a necessary step towards memory safety. Motivation Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8. However, there is a catch: V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today.
As you follow along with the code in the book, you may find yourself needing to debug some generated wasm. One of the best tools for doing that is Yury Delendik’s WebAssembly Code Explorer. You can upload a .wasm file, and it will show you an interactive visualization along a the text representation of the module (.wat). It even works with modules that are not valid. Note that if the module is invalid, the output you see might look very different from what you’re expecting. But often, seeing how how the module is parsed — especially when it’s different from what you intended — is enough to realize where the problem is. We also recommend installing the wabt (WebAssembly Binary Toolkit) tools. You can find installation instructions on the GitHub page.
The image shows a web page titled "wasm2wat demo”, showing a tool that converts WebAssembly binary format to text format. The interface features multiple checkboxes for various WebAssembly features, and options to pass to wasm2wat. There's a pink arrow labeled "New!” pointing to the checkbox for “Check for invalid modules”.
An excerpt from the book, showing a section title "Our first compiler". Let’s create a function that: - Takes the code for a program as input. - “Parses” it by checking that it’s a valid program, in this case the empty string. - Returns an array of bytes which encodes a minimal WebAssembly module.
Learn Wasm by building a simple compiler in JavaScript. No compiler expertise necessary. All the code is in the book; we'll take you through it step by step. Get your hands dirty and see for yourself what WebAssembly is all about.
A table of contents page for 'WebAssembly from the Ground Up' with a purple 'WA' logo. The page is divided into sections: Start, Main Track, Deep Dives, and Finish. The Main Track section includes topics like 'Minimum Viable Compiler', 'Writing a Compiler with Ohm', and several other chapters including two bonus sections marked with sparkle emojis. Some entries in the Deep Dives and Finish sections are marked as 'Draft'. A cartoon pair of eyes appears in the bottom right corner with a pink arrow pointing to the 'Conclusion' section.
"A table of contents showing the structure of a technical book or guide about compilers and programming. The content is divided into sections: START (with Introduction and About the Code), MAIN TRACK (containing topics like Minimum Viable Compiler, Writing a Compiler with Ohm, and various programming concepts), DEEP DIVES (with technical topics like Variable-Length Integer Encoding), and FINISH (with Conclusion and final sections). Some entries are marked as 'Draft' or 'Planned'. There's a pink arrow pointing to 'Appendix: Odds & Ends' with text saying 'The last technical chapter!!!'"
Arrays and Strings In the last chapter, we added basic support to Wafer for reading and writing linear memory. We can now create modules with memory, and access it directly as if it was a single big array of i32 values. Our first goal in this chapter is to use that functionality to add support for regular, dynamically-allocated i32 arrays. In order to do that, we’ll need to write a simple memory allocator. Then, building on i32 arrays, we’ll add support for strings to Wafer — which means we’ll finally be able to write “Hello, world!”
A compatibility table showing WebAssembly feature support across different platforms and browsers. The table includes logos for Chrome, Firefox, Safari, Node.js, Deno, GraalWasm, Wastime, and Wasmer. The row highlighted in pink shows "Garbage Collection" feature support, with version numbers 119 for Chrome, 120 for Firefox, 18.2 for Safari, 22.0 for Node.js, and 1.38 for Deno
WebKit for Safari 18.2 adds support for WASM Garbage Collection. It allows WebAssembly modules to define a variety of new reference types whose memory is managed automatically by the browser. These types range from simple data types like structs and arrays, to more complex type relationships such as subtyping and recursion. Without WASM GC, source languages that rely on garbage collection (such as Java, C#, Kotlin, Go, and others) generally have to write their own garbage collectors and compile them to WebAssembly. … WebKit for Safari 18.2 also adds support for WASM Tail Calls, which allows WebAssembly modules to call functions while reusing the current stack frame.