WebAssembly from the Ground Up
LightNews LightNews
banner
wasmgroundup.com
WebAssembly from the Ground Up
@wasmgroundup.com
240 followers 190 following 65 posts
A book about WebAssembly by @marianoguerra.org and @dubroy.com — learn Wasm by building a simple compiler in JavaScript.

https://wasmgroundup.com/
Posts Replies Media Videos
wasmgroundup.com
We just sent out our last newsletter of the year, chock full of Wasm tidbits and captivating compiler content.

Not signed up? You're missing out!

Get on the list at sendfox.com/wasmgroundup
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.
December 18, 2025 at 3:06 PM
wasmgroundup.com
A very readable doc about V8's new bytecode verifier.

Readers of our book may notice the similarity to the Wasm security model — see this excerpt from the chapter "What makes WebAssembly safe?"
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." An excerpt from WebAssembly from the Ground Up, showing a section entitled "Sandboxed execution". The excerpt reads: "WebAssembly sandboxed execution is based on a technique known as Software-based Fault Isolation (SFI). It’s a remarkably simple idea. Here’s how it works — The “sandbox” consists of two regions of memory: a code region and a data region. Then, the host must enforce two policies: - A data-access policy ensures that any memory access in the untrusted module can only target its designated data region. - A control-flow policy ensures that the untrusted module can’t transfer control outside its own code region — except by calling explicitly-allowed functions."
December 9, 2025 at 11:13 AM
wasmgroundup.com
I don't check LinkedIn very often, but today it was worth it. 😊
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!
December 4, 2025 at 4:59 PM
wasmgroundup.com
One of our goals in the book was to encourage readers to become familiar with the WebAssembly spec.

That's why, in the library we create for producing Wasm modules, we aim for "eye-closeness" with the spec.

Left: code from the book.
Right: the 1.0 spec text.
// 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)]; }, }; Excerpt from the WebAssembly core specification show § 5.5.5. Import Section, and the definitions of `importsec`, `import`, and `importdesc`.
November 21, 2025 at 11:13 AM
wasmgroundup.com
Oh hey! We're on the HN front page 😄

If you've read the book and enjoyed it, and feel like leaving a comment, it would certainly help us out!
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.
November 21, 2025 at 10:24 AM
wasmgroundup.com
Wasm Maze by Kenny Fully
→ kennyfully881230.github.io/wasm_fun/was...

"I ended up learning a lot about how to use linear memory to render one time to the canvas on every frame. Not only that, I learn how to do collisions, sprite clipping etc all in Wasm."

Source code: github.com/kennyfully88...
November 20, 2025 at 4:06 PM
wasmgroundup.com
Interesting paper presented at MPLR yesterday — "A Snapshot of the Performance of Wasm Backends for Managed Languages"
→ users.cs.northwestern.edu/~robby/pubs/...

Benchmarks Wasm implementations of Dart, Haskell, Scheme, OCaml, Ruby against the native impls.
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.
October 14, 2025 at 4:34 AM
wasmgroundup.com
An interesting article about how Figma moved from WebGL to WebGPU —

Figma rendering: Powered by WebGPU
→ www.figma.com/blog/figma-r...

Also talks a bit about their overall app architecture, and how they use #wasm.
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.
September 29, 2025 at 2:36 PM
wasmgroundup.com
Nice use of Wasm — bundling lightweight WebAssembly decoders with the data.

AnyBlox: A Framework for Self-Decoding Datasets
→ gienieczko.com/anyblox-paper

/ht Jamie Brandon (www.scattered-thoughts.net/log/0054/)
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."
September 12, 2025 at 1:09 PM
wasmgroundup.com
A good question we were asked recently —

"Does V8 optimize WebAssembly similar to JS?"

The latest post on the V8 blog, "Speculative Optimizations for WebAssembly using Deopts and Inlining", provides some answers!

v8.dev/blog/wasm-s...
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.
June 26, 2025 at 7:58 AM
wasmgroundup.com
Wireworld is a kind of cellular automaton, similar to Conway's Game of Life.

Wasm4-Wireworld is an implementation of Wireworld WASM-4 "fantasy console" using Hoot, a Scheme-to-Wasm compiler: spritely.institute/news/hoot-wi...
April 25, 2025 at 3:29 PM
wasmgroundup.com
Great article by @saelo.bsky.social about the V8 sandbox: v8.dev/blog/sandbox

"the overall construction is therefore not unlike the sandboxing model used by WebAssembly"
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.
April 17, 2025 at 8:27 AM
wasmgroundup.com
Just published a new release of the book with some minor updates:

• Added "debugging" section to About the Code
• Appendix now has all remaining instructions from the 1.0 spec
• (PDF) Fixed some code blocks which didn't show full contents

+More! It's all in the changelog.
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.
April 10, 2025 at 3:43 PM
wasmgroundup.com
Something handy for anyone who's trying to debug generated wasm…

A PR of ours was merged into the wabt repo yesterday. In the JS version of wasm2wat, you can now opt to skip validation — just like the `--no-check` option in the CLI.

Try it out here: webassembly.github.io/wabt/demo/w...
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”.
April 10, 2025 at 8:47 AM
wasmgroundup.com
Here's a peek inside the book. You can also read a few sample chapters here: wasmgroundup.com/book/content...
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.
March 12, 2025 at 4:40 PM
wasmgroundup.com
Excited to announce the official launch of our online book, WebAssembly from the Ground Up! 🎉

It's the book we wish we'd had 3 years ago.

No messing with tools and frameworks. It's a hands-on guide to the core of Wasm: the instruction set and module format.

Link below. 👇
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.
March 10, 2025 at 1:19 PM
wasmgroundup.com
With the official launch of the book being next week, we figured it's about time we wrote a Conclusion chapter 😅

Lots more small tweaks & improvements coming this week…
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 conclusion page from a WebAssembly book, titled 'Conclusion' with the subtitle 'What we covered (and what we didn't)'. The text discusses the book's focus on WebAssembly Core Specification 1.0, listing four main topics covered: the execution model, binary module format (.wasm), validation rules, and text format (.wat). The text explains that the book primarily focused on the first two topics while acknowledging that not everything could be covered comprehensively.
February 24, 2025 at 2:54 PM
wasmgroundup.com
Just published another update to the book: a draft of our last technical chapter, "Odds & Ends". 🎉

It covers a few features that we didn't have room for in the main track of the book: global variables, tables, and the element 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!!!'" A documentation page about WebAssembly global variables. The left side shows a navigation menu with sections like 'Odds and Ends', 'Export types', and 'Global variables'. The main content includes explanatory text and two code blocks in dark mode. The first code block shows global instruction definitions in JavaScript with hexadecimal values (0x23 and 0x24). The second code block contains more complex JavaScript code defining global section constants and functions, including SECTION_ID_GLOBAL set to 6, mutation types, and helper functions for handling global variables. The code is syntax-highlighted in shades of blue and white
February 14, 2025 at 2:30 PM
wasmgroundup.com
Happy Friday! We've just published a draft of the FINAL technical chapter of the book.

It's called "What Makes WebAssembly Safe?" and we think you're going to enjoy it.
January 31, 2025 at 3:51 PM
wasmgroundup.com
Nice to see that @moonbitlang.bsky.social is continuing to make progress!

MoonBit is a new, Wasm-native programming language with a syntax similar to Rust (although it has a GC): docs.moonbitlang.com/en/latest/
January 24, 2025 at 12:25 PM
wasmgroundup.com
SpiderMonkey WASI demo — the SpiderMonkey JS engine, compiled to WebAssembly, running in the browser
→ mozilla-spidermonkey.github.io/sm-wasi-demo/
January 18, 2025 at 7:12 PM
wasmgroundup.com
Love this idea!

WebAssembly Wizardry: "Tiny programming challenges designed for learning about WebAssembly by writing it by hand."
→ github.com/danprince/w...
December 28, 2024 at 10:29 AM
wasmgroundup.com
Hello! We're looking for 1-2 people **who've already bought the book but haven't yet started** and are interesting in working through the first 1-2 chapters LIVE on a video call with me.

Interested? Reply here or to the post on the #announcements channel in the book's Discord.
December 21, 2024 at 12:56 PM
wasmgroundup.com
This is the final chapter in the main part of the book. That means…we're almost done!

With today's release, we've also removed draft status from Chap. 7–9. Early next year, we'll be releasing the final chapter, a deep dive on what makes WebAssembly "safe".

And then…launch! 🚀
December 16, 2024 at 2:37 PM
wasmgroundup.com
Hello Wasmites —

We've got a big update for you today, just in time for the holidays! It's a draft of Chapter 10: Arrays and Strings. 🎉

This is definitely one of the most technically challenging chapters of the book…but we think you're going to like it!
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!” Bounds checking We can make our arrays more user friendly by implementing bounds checking. That is, before reading or writing memory, we’ll check that the index is valid — that it’s within the bounds of the array. The way we’ll do that is by storing the array length at the beginning of every array. So an array of length 2 will now take up three i32 slots: one for the length, and two for the entries themselves.
December 16, 2024 at 2:37 PM