WebAssembly from the Ground Up
LightNews LightNews
banner
wasmgroundup.com
WebAssembly from the Ground Up
@wasmgroundup.com
230 followers 190 following 53 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
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
wasmgroundup.com
It's really good news for dynamic languages. WasmGC is now supported in all the major browsers and JS runtimes.
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
December 12, 2024 at 11:49 AM
wasmgroundup.com
Big news! Safari 18.2 is out, with support for WasmGC and tail calls: webkit.org/blog/16301/...
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.
December 12, 2024 at 11:49 AM
wasmgroundup.com
Turns out there's a lot of stuff to cover before we can print to the console.

- Building an instantiating modules
- Defining functions
- Importing functions
- Linear memory
etc.

Yes, we like doing things the hard way.
December 11, 2024 at 2:51 PM
wasmgroundup.com
Many programming books start with a small program that prints "Hello, world.”

But this book is different. It's only at the end of Chapter 10 that we're ready to tackle that. 😅

Looking forward to releasing the draft very soon!
December 11, 2024 at 2:51 PM
wasmgroundup.com
Some *very* interesting Wasm-related features in the latest version of Deno (v2.1): https://docs.deno.com/runtime/reference/wasm/

• Import .wasm modules directly
• Calls into WebAssembly are type checked (!)
• Wasm modules can import .ts modules directly (!!)
November 22, 2024 at 5:19 PM
wasmgroundup.com
Hello, World! (from the ground up)
November 22, 2024 at 1:20 PM