What is WebAssembly? The Binary Format Eating the Web (and Leaving the Browser)
WebAssembly started as a way to run C++ in a browser without recompiling to JavaScript. Figma, Google Earth, AutoCAD, and video codecs run in WASM. The server-side ecosystem is growing fast enough that cloud providers are building WASM runtimes into their infrastructure. Here is how it works.
JavaScript runs everywhere. Every browser ships a JavaScript engine. The web was built on it, the mobile web runs on it, and Node.js took it server-side. JavaScript is the most widely deployed programming language on the planet by some measures.
JavaScript is also a dynamically typed scripting language that was designed in ten days. It handles most web UI work perfectly well. It handles CPU-intensive computation, image processing, physics simulations, 3D rendering, and video codec work poorly. The V8 engine is an engineering marvel that makes JavaScript faster than it has any right to be, but JIT-compiled JavaScript still runs 5 to 10 times slower than equivalent native code for compute-bound tasks. For many applications, that gap does not matter. For some, it is the difference between possible and impossible.
WebAssembly is the solution. Not a replacement for JavaScript. A complement to it. A binary instruction format that runs at near-native speed in the same environment as JavaScript, with access to the same browser APIs, manipulatable from JavaScript code. Write performance-critical code in Rust, C, C++, or a growing list of other languages, compile it to WebAssembly, and run it in the browser with predictable, fast execution.
Then the technology left the browser and became something else entirely.
What WebAssembly Actually Is
WebAssembly (Wasm) is a binary instruction format for a stack-based virtual machine. The W3C standardized it in 2019 as the fourth official web language alongside HTML, CSS, and JavaScript. Every major browser ships a Wasm runtime: Chrome/V8, Firefox/SpiderMonkey, Safari/JavaScriptCore, Edge/Chakra.
The design goals, from the official specification: fast (native execution speed), safe (memory-safe, sandboxed execution), portable (deterministic behavior across platforms), and compact (binary format smaller than equivalent text formats).
Wasm is not a language you write. It is a compilation target. Rust, C, C++, Go, AssemblyScript (TypeScript-like syntax), Kotlin, Swift, and a dozen other languages can compile to Wasm. You write in your language of choice, compile to .wasm binary files, and load those files in the browser or a Wasm runtime.
The virtual machine model is what gives Wasm its safety properties. Wasm code runs in a sandboxed environment. It cannot access memory outside its allocated linear memory space. It cannot make arbitrary system calls. It cannot reach outside the sandbox without explicit permission granted by the host environment. This containment is what makes it safe to run untrusted Wasm code, which is what every browser does when it loads a Wasm module from a website.
Wasm's memory model is a contiguous, resizable byte array called linear memory. The Wasm module reads and writes to this array using load and store instructions. It cannot access the host's memory outside this array. JavaScript can read and write to this same memory through WebAssembly.Memory, which is how Wasm and JavaScript share data without expensive serialization.
The Problem Wasm Solved
The pre-Wasm story for compute-intensive browser applications was Emscripten and asm.js. Emscripten compiled C/C++ to a highly optimized subset of JavaScript called asm.js. The JavaScript engine, seeing the asm.js pragma annotations, could apply more aggressive optimizations and avoid some of the overhead of dynamic typing. Games, physics engines, and media processing code compiled with Emscripten could run at 50-60% of native speed in a browser.
This worked. Mozilla ported the Unreal Engine 4 to asm.js and demonstrated it running in a browser at 60fps. Figma's original collaborative design tool used it. But asm.js had limits: the binary format was massive (JavaScript text is verbose), parsing took time, and the optimizations available to the JavaScript engine were still constrained by the language's semantics.
WebAssembly replaced asm.js with a proper binary format and a proper virtual machine specification. The binary format is compact. Parsing is fast because binary is structurally simpler than text. The VM specification is precise enough that all compliant engines produce the same results. The JIT compiler for Wasm can apply optimizations that are not available for JavaScript because Wasm's type system is explicit and immutable at runtime.
The performance improvement over asm.js was significant. Startup time dropped because smaller binaries parse faster. Peak performance improved because the JIT had more freedom to optimize. Predictability improved because Wasm's execution semantics have fewer dynamic edge cases.
Rust to WebAssembly
Rust is the language most commonly used with Wasm in production today. Rust has no garbage collector, which means no GC pauses at runtime. Rust's ownership system eliminates entire classes of memory bugs at compile time. The resulting Wasm modules are small (no runtime included beyond what the code needs) and fast.
Here is a complete Rust Wasm library for image processing:
use wasm_bindgen::prelude::*;
use web_sys::{ImageData, CanvasRenderingContext2d};
use std::f64;
#[wasm_bindgen]
pub struct ImageProcessor {
width: u32,
height: u32,
data: Vec<u8>,
}
#[wasm_bindgen]
impl ImageProcessor {
#[wasm_bindgen(constructor)]
pub fn new(width: u32, height: u32, data: Vec<u8>) -> Result<ImageProcessor, JsValue> {
if data.len() != (width * height * 4) as usize {
return Err(JsValue::from_str("Data length does not match dimensions"));
}
Ok(ImageProcessor { width, height, data })
}
pub fn grayscale(&mut self) {
for chunk in self.data.chunks_mut(4) {
let r = chunk[0] as f32;
let g = chunk[1] as f32;
let b = chunk[2] as f32;
let gray = (0.299 * r + 0.587 * g + 0.114 * b) as u8;
chunk[0] = gray;
chunk[1] = gray;
chunk[2] = gray;
}
}
pub fn brightness(&mut self, amount: i32) {
for chunk in self.data.chunks_mut(4) {
chunk[0] = (chunk[0] as i32 + amount).clamp(0, 255) as u8;
chunk[1] = (chunk[1] as i32 + amount).clamp(0, 255) as u8;
chunk[2] = (chunk[2] as i32 + amount).clamp(0, 255) as u8;
}
}
pub fn contrast(&mut self, factor: f32) {
let factor = (259.0 * (factor + 255.0)) / (255.0 * (259.0 - factor));
for chunk in self.data.chunks_mut(4) {
chunk[0] = ((factor * (chunk[0] as f32 - 128.0) + 128.0).clamp(0.0, 255.0)) as u8;
chunk[1] = ((factor * (chunk[1] as f32 - 128.0) + 128.0).clamp(0.0, 255.0)) as u8;
chunk[2] = ((factor * (chunk[2] as f32 - 128.0) + 128.0).clamp(0.0, 255.0)) as u8;
}
}
pub fn gaussian_blur(&mut self, sigma: f64) {
let kernel_size = ((6.0 * sigma) as usize | 1).max(3);
let half = kernel_size / 2;
let mut kernel = vec![0.0f64; kernel_size];
let mut sum = 0.0f64;
for i in 0..kernel_size {
let x = i as f64 - half as f64;
kernel[i] = (-x * x / (2.0 * sigma * sigma)).exp();
sum += kernel[i];
}
for k in kernel.iter_mut() { *k /= sum; }
let mut temp = self.data.clone();
let w = self.width as usize;
let h = self.height as usize;
for y in 0..h {
for x in 0..w {
for c in 0..3usize {
let mut val = 0.0f64;
for (ki, &kv) in kernel.iter().enumerate() {
let sx = (x as i64 + ki as i64 - half as i64).clamp(0, w as i64 - 1) as usize;
val += self.data[(y * w + sx) * 4 + c] as f64 * kv;
}
temp[(y * w + x) * 4 + c] = val as u8;
}
}
}
let data_after_horiz = temp.clone();
for y in 0..h {
for x in 0..w {
for c in 0..3usize {
let mut val = 0.0f64;
for (ki, &kv) in kernel.iter().enumerate() {
let sy = (y as i64 + ki as i64 - half as i64).clamp(0, h as i64 - 1) as usize;
val += data_after_horiz[(sy * w + x) * 4 + c] as f64 * kv;
}
self.data[(y * w + x) * 4 + c] = val as u8;
}
}
}
}
pub fn get_data(&self) -> Vec<u8> {
self.data.clone()
}
pub fn pixel_count(&self) -> u32 {
self.width * self.height
}
}
#[wasm_bindgen]
pub fn detect_edges_sobel(data: &[u8], width: u32, height: u32) -> Vec<u8> {
let w = width as usize;
let h = height as usize;
let mut output = vec![0u8; data.len()];
let sobel_x: [[i32; 3]; 3] = [[-1, 0, 1], [-2, 0, 2], [-1, 0, 1]];
let sobel_y: [[i32; 3]; 3] = [[-1, -2, -1], [0, 0, 0], [1, 2, 1]];
for y in 1..h-1 {
for x in 1..w-1 {
let mut gx = 0i32;
let mut gy = 0i32;
for ky in 0..3 {
for kx in 0..3 {
let px = x + kx - 1;
let py = y + ky - 1;
let idx = (py * w + px) * 4;
let gray = (data[idx] as i32 + data[idx+1] as i32 + data[idx+2] as i32) / 3;
gx += gray * sobel_x[ky][kx];
gy += gray * sobel_y[ky][kx];
}
}
let magnitude = ((gx * gx + gy * gy) as f64).sqrt().min(255.0) as u8;
let out_idx = (y * w + x) * 4;
output[out_idx] = magnitude;
output[out_idx+1] = magnitude;
output[out_idx+2] = magnitude;
output[out_idx+3] = 255;
}
}
output
}
#[wasm_bindgen]
pub fn compute_histogram(data: &[u8]) -> Vec<u32> {
let mut histogram = vec![0u32; 256 * 3];
for chunk in data.chunks(4) {
histogram[chunk[0] as usize] += 1;
histogram[256 + chunk[1] as usize] += 1;
histogram[512 + chunk[2] as usize] += 1;
}
histogram
}
Build configuration in Cargo.toml:
[package]
name = "image-processor"
version = "0.1.0"
edition = "2021"
[lib]
crate-type = ["cdylib"]
[dependencies]
wasm-bindgen = "0.2"
web-sys = { version = "0.3", features = ["ImageData", "CanvasRenderingContext2d"] }
console_error_panic_hook = "0.1"
[profile.release]
opt-level = "z"
lto = true
codegen-units = 1
Build it:
wasm-pack build --target web --out-dir pkg
wasm-pack calls cargo build --target wasm32-unknown-unknown, then uses wasm-bindgen to generate JavaScript glue code that bridges the Wasm module with the browser's JavaScript environment. The output in pkg/ includes the .wasm binary, a JavaScript wrapper, and TypeScript type definitions.
Using it in JavaScript:
import init, { ImageProcessor, detect_edges_sobel, compute_histogram } from './pkg/image_processor.js';
async function processImage(canvas) {
await init();
const ctx = canvas.getContext('2d');
const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);
const { data, width, height } = imageData;
const processor = new ImageProcessor(width, height, data);
console.time('wasm-processing');
processor.grayscale();
processor.brightness(20);
processor.gaussian_blur(1.5);
const processedData = processor.get_data();
const histogram = compute_histogram(processedData);
const edges = detect_edges_sobel(processedData, width, height);
console.timeEnd('wasm-processing');
const outputImageData = new ImageData(
new Uint8ClampedArray(edges),
width,
height
);
ctx.putImageData(outputImageData, 0, 0);
const rgbHistogram = {
red: Array.from(histogram.slice(0, 256)),
green: Array.from(histogram.slice(256, 512)),
blue: Array.from(histogram.slice(512, 768))
};
return { pixelCount: processor.pixel_count(), histogram: rgbHistogram };
}
await init() loads and instantiates the Wasm module. The first call does the work. Subsequent calls are instant because the module is cached. ImageProcessor is a JavaScript class that wraps the Rust struct. Methods on it call into the Wasm module. The Rust objects are allocated in Wasm's linear memory, not the JavaScript heap.
The Gaussian blur on a 4K image processes roughly 8 million pixel operations. In JavaScript, this takes several seconds with visible UI freezing. In Wasm, it completes in 50-150ms. That is not a small optimization. It is the difference between a feature being usable and being unusable.
How Wasm Works: The Binary Format
Understanding what Wasm actually is under the hood demystifies why it performs the way it does.
A .wasm file is a binary file organized into sections: type section (function signatures), import section (functions/globals imported from the host), function section (indices into the type section for each function), export section (functions/globals exposed to the host), code section (function bodies), data section (initial memory contents), and optional debug sections.
The WAT (WebAssembly Text Format) is the human-readable equivalent. The .wasm binary and .wat text format are interconvertible. Understanding WAT is not required for using Wasm, but it is useful for debugging and understanding what your compiled code actually does.
(module
(type $add_type (func (param i32 i32) (result i32)))
(type $factorial_type (func (param i64) (result i64)))
(func $add (type $add_type)
local.get 0
local.get 1
i32.add)
(func $factorial (type $factorial_type)
(local $result i64)
i64.const 1
local.set $result
(block $break
(loop $loop
local.get 0
i64.const 1
i64.le_s
br_if $break
local.get $result
local.get 0
i64.mul
local.set $result
local.get 0
i64.const 1
i64.sub
local.set 0
br $loop))
local.get $result)
(export "add" (func $add))
(export "factorial" (func $factorial)))
The stack-based virtual machine pops operands from the stack and pushes results. local.get 0 pushes the first parameter. local.get 1 pushes the second. i32.add pops two i32 values, adds them, and pushes the result. The function returns whatever is on top of the stack when it exits.
The four numeric types are i32, i64, f32, and f64. WebAssembly 1.0 has no strings, no objects, no garbage collection. These are low-level machine-like types. The simplicity is intentional: fewer types means simpler JIT compilation and more predictable performance.
The GC proposal (now part of Wasm 2.0) adds garbage-collected reference types, enabling languages with GC (Java, Python, C#, Kotlin) to compile to Wasm without including their entire runtime as a bundled blob. This is what makes Wasm viable as a compilation target for the JVM ecosystem at reasonable binary sizes.
Real Applications Running Wasm
The applications running Wasm in production today are the best argument for what the technology enables.
Figma built their vector design tool using a C++ rendering engine compiled to Wasm. The rendering, layout, and geometry computation runs in Wasm. The UI and collaboration features run in JavaScript. When you manipulate complex design files with thousands of objects, you are hitting a Wasm module that is applying vector math at near-native speed. Figma's competitors built similar tools and shipped them as desktop applications. Figma shipped in the browser by using Wasm for the computation that JavaScript could not handle.
Google Earth runs in browsers using Wasm. The 3D globe, terrain rendering, and imagery streaming engine is C++ compiled to Wasm. The original Google Earth required a native plugin. The Wasm version runs in any browser without installation.
AutoCAD shipped a browser version of their CAD software using Wasm. CAD software is one of the most computationally intensive desktop application categories. The fact that it runs at acceptable performance in a browser tab is a direct result of Wasm's near-native execution speed for compute-intensive code.
Zoom uses Wasm for their background replacement feature. The ML model that segments you from your background and composites in the virtual background runs in a Wasm module. This is image processing code that needs to run at 30fps without blocking the UI thread. Wasm runs it off the main thread via Web Workers.
Adobe has shipped Photoshop for the web using Wasm. The core image processing operations in Photoshop, some of which have been optimized in C++ over thirty years, compile to Wasm and run in the browser.
The pattern across these is the same: C++ code that has been written, optimized, and tested for years on the desktop can now run in the browser without a complete rewrite. The investment in native code is not abandoned. It is redeployed.
WebAssembly Outside the Browser: WASI
In 2019, Solomon Hykes, the creator of Docker, wrote on Twitter: "If WASM+WASI existed in 2008, we wouldn't have needed to create Docker. That's how important it is. WebAssembly on the server is the future of computing."
WASI (WebAssembly System Interface) is a standardized API for WebAssembly modules to interact with the operating system: reading files, making network connections, getting the current time, writing to stdout. WASI defines these capabilities as standardized interfaces, and Wasm runtimes implement them.
The implication: a Wasm module compiled for WASI can run on any operating system with a compatible runtime, without modification. The same binary runs on Linux, macOS, Windows, and embedded systems. WASM+WASI gives you portability that is even more absolute than Java's "write once, run anywhere" promise, because the Wasm binary is smaller and the startup time is measured in microseconds instead of hundreds of milliseconds.
Server-side Wasm runtimes: Wasmtime (Bytecode Alliance, Rust), WasmEdge (used by Docker, cloud-native workloads), WAMR (embedded systems), Wasmer (polyglot runtime).
Fermyon's Spin framework runs Wasm modules as serverless functions with startup times under a millisecond, compared to Node.js cold starts of 200-500ms or Java cold starts of several seconds. Cloudflare Workers supports Wasm modules running at the edge globally. Fastly Compute@Edge runs Wasm. The cloud providers are betting on Wasm as the next generation of serverless compute.
Here is a Rust WASI program that processes data like a serverless function:
use std::io::{self, Read};
use serde::{Deserialize, Serialize};
use serde_json;
#[derive(Deserialize)]
struct InputData {
values: Vec<f64>,
operation: String,
}
#[derive(Serialize)]
struct OutputData {
result: f64,
count: usize,
operation: String,
success: bool,
error: Option<String>,
}
fn process(input: &InputData) -> Result<f64, String> {
if input.values.is_empty() {
return Err("No values provided".to_string());
}
match input.operation.as_str() {
"sum" => Ok(input.values.iter().sum()),
"mean" => Ok(input.values.iter().sum::<f64>() / input.values.len() as f64),
"max" => input.values.iter().cloned().reduce(f64::max)
.ok_or_else(|| "Could not compute max".to_string()),
"min" => input.values.iter().cloned().reduce(f64::min)
.ok_or_else(|| "Could not compute min".to_string()),
"variance" => {
let mean = input.values.iter().sum::<f64>() / input.values.len() as f64;
let variance = input.values.iter()
.map(|&x| (x - mean).powi(2))
.sum::<f64>() / input.values.len() as f64;
Ok(variance)
},
"std_dev" => {
let mean = input.values.iter().sum::<f64>() / input.values.len() as f64;
let variance = input.values.iter()
.map(|&x| (x - mean).powi(2))
.sum::<f64>() / input.values.len() as f64;
Ok(variance.sqrt())
},
op => Err(format!("Unknown operation: {}", op)),
}
}
fn main() {
let mut input = String::new();
io::stdin().read_to_string(&mut input)
.expect("Failed to read stdin");
let output: OutputData = match serde_json::from_str::<InputData>(&input) {
Ok(data) => {
let count = data.values.len();
let operation = data.operation.clone();
match process(&data) {
Ok(result) => OutputData { result, count, operation, success: true, error: None },
Err(e) => OutputData { result: 0.0, count, operation, success: false, error: Some(e) },
}
}
Err(e) => OutputData {
result: 0.0, count: 0,
operation: "unknown".to_string(),
success: false,
error: Some(format!("Parse error: {}", e)),
}
};
println!("{}", serde_json::to_string(&output).unwrap());
}
Build it:
cargo build --target wasm32-wasip1 --release
Run it:
echo '{"values": [1, 2, 3, 4, 5], "operation": "mean"}' | \
wasmtime target/wasm32-wasip1/release/my_processor.wasm
This binary runs identically on any machine with a WASI-compatible runtime. No Docker container. No language runtime. No operating system dependencies beyond the runtime itself. The binary is small (typically 200KB to a few MB for a Rust program after wasm-opt optimization), starts in microseconds, and runs in a sandboxed environment where it can only do what you explicitly permit.
For serverless functions that need fast cold starts and strong isolation, this is compelling. For plugins that need to run untrusted user code inside your application safely, this is the right architecture. For distributing computation to edge locations globally, this is how Cloudflare and Fastly have deployed it.
The Component Model
Wasm's original module system had a problem: modules could only share linear memory and basic numeric types. Passing a string between two Wasm modules required encoding it into bytes, writing those bytes to shared memory, passing a pointer and length, and decoding on the other side. Composing Wasm modules was painful.
The Component Model, now part of the WASI 0.2 specification, defines a richer type system and interface definition language (WIT - WebAssembly Interface Types) for composing Wasm modules. You define interfaces in WIT:
package example:[email protected];
interface calculator {
record stats-result {
mean: f64,
variance: f64,
std-dev: f64,
min: f64,
max: f64,
count: u32,
}
compute-stats: func(values: list<f64>) -> result<stats-result, string>;
compute-percentile: func(values: list<f64>, percentile: f64) -> result<f64, string>;
}
world stats-component {
export calculator;
}
Any language that supports the Component Model can implement or consume this interface. A Rust component can call a Go component can call a Python component, passing typed data without serialization overhead, through a standardized interface that the toolchain generates bindings for. This is the vision: language-agnostic software components that compose cleanly without protocol negotiation.
The Limitations
Wasm is not without constraints. The DOM is not directly accessible from Wasm. Manipulating web page elements requires calling back into JavaScript, which has overhead. For CPU-intensive computation that does not touch the DOM, this is fine. For UI code that continuously reads and writes the DOM, Wasm does not help and may add overhead compared to JavaScript.
The debugging experience lags behind native development. Source maps exist and most browsers have basic Wasm debugging support, but setting breakpoints in Rust or C++ code running as Wasm is still rougher than debugging native code in a proper IDE.
Binary size requires attention. A Rust Wasm binary is typically 500KB to several MB before optimization. wasm-opt (from Binaryen) and release builds with LTO reduce this significantly, but Wasm is not appropriate for cases where initial load size is the dominant concern. Incremental loading and caching mitigate this for returning users.
The GC proposal is still rolling out across the ecosystem. Languages that need GC (Kotlin, Dart, Python, C#) currently either embed their entire runtime in the Wasm binary (large files) or wait for GC proposal support in their toolchains. Kotlin Wasm is progressing. Blazor (C# on Wasm) ships with the .NET runtime in the binary, resulting in 6-10MB downloads for a simple app.
AssemblyScript: TypeScript for WebAssembly
Not every Wasm use case requires Rust or C++. AssemblyScript is a strict subset of TypeScript that compiles to Wasm. If your team already knows TypeScript, AssemblyScript provides a lower-friction path to Wasm for performance-sensitive logic.
// assembly/index.ts
export function fibonacci(n: i32): i64 {
if (n <= 1) return n as i64;
let a: i64 = 0;
let b: i64 = 1;
for (let i: i32 = 2; i <= n; i++) {
const temp: i64 = a + b;
a = b;
b = temp;
}
return b;
}
export function sumArray(ptr: i32, length: i32): f64 {
let sum: f64 = 0;
for (let i: i32 = 0; i < length; i++) {
sum += load<f64>(ptr + i * 8);
}
return sum;
}
export function sortDescending(ptr: i32, length: i32): void {
for (let i: i32 = 0; i < length - 1; i++) {
for (let j: i32 = 0; j < length - i - 1; j++) {
const a = load<f64>(ptr + j * 8);
const b = load<f64>(ptr + (j + 1) * 8);
if (a < b) {
store<f64>(ptr + j * 8, b);
store<f64>(ptr + (j + 1) * 8, a);
}
}
}
}
@inline
export function clamp(value: f64, min: f64, max: f64): f64 {
return value < min ? min : (value > max ? max : value);
}
export function normalizeArray(ptr: i32, length: i32): void {
let min: f64 = f64.MAX_VALUE;
let max: f64 = f64.MIN_VALUE;
for (let i: i32 = 0; i < length; i++) {
const val = load<f64>(ptr + i * 8);
if (val < min) min = val;
if (val > max) max = val;
}
const range: f64 = max - min;
if (range == 0) return;
for (let i: i32 = 0; i < length; i++) {
const val = load<f64>(ptr + i * 8);
store<f64>(ptr + i * 8, (val - min) / range);
}
}
Build it:
npm install --save-dev assemblyscript
npx asc assembly/index.ts --target release --outFile build/release.wasm --optimizeLevel 3
Using it from JavaScript:
import { instantiate } from '@assemblyscript/loader';
import fs from 'fs';
async function loadWasm() {
const wasmBuffer = fs.readFileSync('./build/release.wasm');
const { exports } = await instantiate(wasmBuffer, {});
const { fibonacci, sumArray, sortDescending, normalizeArray, memory } = exports;
console.log('fibonacci(40):', fibonacci(40));
console.log('fibonacci(50):', fibonacci(50));
const data = new Float64Array([5.0, 3.0, 8.0, 1.0, 9.0, 2.0, 7.0, 4.0, 6.0]);
const ptr = exports.__alloc(data.byteLength);
new Float64Array(memory.buffer, ptr, data.length).set(data);
console.log('Sum:', sumArray(ptr, data.length));
sortDescending(ptr, data.length);
const sorted = Array.from(new Float64Array(memory.buffer, ptr, data.length));
console.log('Sorted descending:', sorted);
normalizeArray(ptr, data.length);
const normalized = Array.from(new Float64Array(memory.buffer, ptr, data.length));
console.log('Normalized:', normalized.map(v => v.toFixed(3)));
exports.__unpin(ptr);
}
loadWasm();
AssemblyScript's direct memory access through load<f64> and store<f64> is lower-level than typical TypeScript. You are working with byte offsets into the Wasm linear memory. This is intentional: AssemblyScript compiles to efficient Wasm because you opt into manual memory management for hot paths. For less performance-critical code, AssemblyScript provides managed classes and garbage-collected objects at the cost of some runtime overhead.
The tradeoff between Rust and AssemblyScript for Wasm: Rust produces smaller, faster binaries with stronger safety guarantees. AssemblyScript has a much shallower learning curve for JavaScript developers and a faster iteration cycle. For a team that wants to add one performance-critical module to an existing JavaScript application without learning a new language ecosystem, AssemblyScript is worth evaluating.
Performance Benchmarks: What the Numbers Look Like
Benchmarks are always context-dependent, but understanding the performance characteristics of Wasm versus JavaScript for different workload types helps you decide when Wasm is worth the complexity.
For CPU-bound numerical computation (array operations, matrix math, sorting, hashing), Wasm consistently runs 3-10x faster than JavaScript. For the specific case of SIMD operations (operating on multiple values in parallel using hardware vector instructions), the Wasm SIMD proposal enables throughput that is 8-16x better than scalar JavaScript.
For I/O-bound operations (DOM manipulation, network requests, file access), Wasm provides no benefit and adds overhead from the JavaScript-Wasm boundary crossing. If your bottleneck is waiting for a fetch request to complete, Wasm does not help.
The call boundary between JavaScript and Wasm has overhead. Calling a Wasm function from JavaScript is cheap for simple numeric arguments (a few nanoseconds). Passing complex data like strings or arrays requires copying data into/out of Wasm linear memory, which adds microseconds. For hot loops that call Wasm on every iteration, the call overhead accumulates. The pattern that works well: pass a large batch of data to Wasm in one call, process it all inside Wasm, return results. Minimize the number of crossings, maximize work done per crossing.
Here is a benchmark comparing approaches for a common pattern, matrix multiplication:
function matmulJS(a, b, n) {
const c = new Float64Array(n * n);
for (let i = 0; i < n; i++) {
for (let k = 0; k < n; k++) {
const aik = a[i * n + k];
for (let j = 0; j < n; j++) {
c[i * n + j] += aik * b[k * n + j];
}
}
}
return c;
}
async function benchmarkMatmul(n = 256) {
const a = new Float64Array(n * n).map(() => Math.random());
const b = new Float64Array(n * n).map(() => Math.random());
const jsStart = performance.now();
for (let run = 0; run < 5; run++) {
matmulJS(a, b, n);
}
const jsTime = (performance.now() - jsStart) / 5;
console.log(`Matrix multiply ${n}x${n}:`);
console.log(` JavaScript: ${jsTime.toFixed(2)}ms`);
}
benchmarkMatmul(256);
benchmarkMatmul(512);
For 512x512 matrix multiplication, JavaScript typically takes 300-500ms depending on the engine. Equivalent Wasm (Rust or C) typically takes 30-80ms. For 3D rendering or physics engines running this computation thousands of times per frame, that gap determines whether you hit 60fps or 6fps.
The Toolchain: Building and Optimizing Wasm
The build toolchain for Wasm has matured significantly. wasm-pack for Rust, emscripten for C/C++, asc for AssemblyScript. The optimization pass matters for production binaries.
wasm-pack build --target web --release
wasm-opt -O3 -o pkg/optimized.wasm pkg/image_processor_bg.wasm
wasm-opt --enable-simd -O3 -o pkg/optimized_simd.wasm pkg/image_processor_bg.wasm
ls -lh pkg/*.wasm
wasm-opt from the Binaryen toolkit applies additional optimizations after the compiler runs. The -O3 flag enables aggressive optimization including dead code elimination, function inlining, and constant propagation. --enable-simd enables SIMD instructions for code that can benefit from them.
The resulting binary size matters for the initial page load. A 200KB Wasm binary downloads in under 100ms on a fast connection and is cached. A 2MB Wasm binary is a significant initial load cost. Use wasm-opt, enable link-time optimization in your build, and strip debug symbols in release builds. For Rust, the Cargo.toml profile settings opt-level = "z" (optimize for size) and lto = true (link-time optimization) reduce binary size substantially.
Threading in WebAssembly
The Wasm threads proposal brings shared memory and atomic operations to the browser. Combined with Web Workers, this enables true parallel computation across CPU cores from browser code.
const workerCode = `
import init, { process_chunk } from './pkg/image_processor.js';
let wasmInitialized = false;
let sharedMemory = null;
self.onmessage = async function(e) {
const { type, data } = e.data;
if (type === 'init') {
sharedMemory = data.memory;
await init(data.wasmModule, sharedMemory);
wasmInitialized = true;
self.postMessage({ type: 'ready' });
return;
}
if (type === 'process') {
const { offset, length, width, operation } = data;
process_chunk(offset, length, width, operation);
self.postMessage({ type: 'done', chunkId: data.chunkId });
}
};
`;
class ParallelImageProcessor {
constructor(numWorkers = navigator.hardwareConcurrency || 4) {
this.numWorkers = numWorkers;
this.workers = [];
this.sharedMemory = null;
this.ready = false;
}
async initialize(wasmModule) {
this.sharedMemory = new WebAssembly.Memory({
initial: 256,
maximum: 512,
shared: true
});
const workerBlob = new Blob([workerCode], { type: 'application/javascript' });
const workerUrl = URL.createObjectURL(workerBlob);
const readyPromises = [];
for (let i = 0; i < this.numWorkers; i++) {
const worker = new Worker(workerUrl, { type: 'module' });
this.workers.push(worker);
readyPromises.push(new Promise(resolve => {
worker.onmessage = (e) => {
if (e.data.type === 'ready') resolve();
};
}));
worker.postMessage({
type: 'init',
data: { wasmModule, memory: this.sharedMemory }
}, [wasmModule]);
}
await Promise.all(readyPromises);
this.ready = true;
URL.revokeObjectURL(workerUrl);
}
async processImage(imageData, operation = 'grayscale') {
if (!this.ready) throw new Error('Processor not initialized');
const { data, width, height } = imageData;
const pixelData = new Uint8Array(this.sharedMemory.buffer, 0, data.length);
pixelData.set(data);
const chunkSize = Math.ceil(height / this.numWorkers);
const chunks = [];
for (let i = 0; i < this.numWorkers; i++) {
const startRow = i * chunkSize;
const endRow = Math.min(startRow + chunkSize, height);
if (startRow >= height) break;
chunks.push({
chunkId: i,
offset: startRow * width * 4,
length: (endRow - startRow) * width * 4,
width,
operation
});
}
await Promise.all(chunks.map((chunk, i) => new Promise(resolve => {
this.workers[i].postMessage({ type: 'process', data: chunk });
this.workers[i].addEventListener('message', function handler(e) {
if (e.data.type === 'done' && e.data.chunkId === chunk.chunkId) {
this.workers[i].removeEventListener('message', handler);
resolve();
}
}.bind(this));
})));
const resultData = new Uint8ClampedArray(this.sharedMemory.buffer, 0, data.length);
return new ImageData(resultData.slice(), width, height);
}
}
WebAssembly.Memory with shared: true creates a SharedArrayBuffer that multiple Web Workers can access simultaneously. The Wasm module in each worker reads and writes different regions of this buffer without copying data between threads. For an image divided into 8 horizontal strips processed by 8 workers, each worker operates on its strip independently, and all eight run in parallel across CPU cores.
Atomic operations (Atomics.wait, Atomics.notify, Atomics.add) synchronize access to shared memory when workers need to coordinate. Wasm's atomic instructions map directly to hardware memory fence instructions, which is what makes lock-free data structures possible in Wasm.
Multi-threaded Wasm requires specific HTTP headers on the server to enable SharedArrayBuffer:
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp
These headers activate cross-origin isolation, which is required for SharedArrayBuffer for security reasons related to Spectre mitigation. Most modern hosting environments and CDNs support these headers.
JavaScript and Wasm: Not Competitors
The frame of "Wasm vs JavaScript" misses the point. The JavaScript event loop, the DOM API, the browser's network APIs, the tooling around React and the frontend ecosystem: none of this goes away. Wasm fills the gap for computation that JavaScript genuinely cannot handle at acceptable performance. JavaScript handles everything else.
Wasm calling JavaScript calling Wasm is the normal pattern. Your JavaScript application loads a Wasm module, calls into it for image processing or physics simulation or compression, and uses the result to update your React UI. The two work together. Figma does this. Zoom does this. Google Earth does this.
The server-side story is more disruptive. Node.js has strong momentum. But Wasm-native serverless compute with microsecond cold starts and strong sandboxing offers capabilities that Node.js cannot match. The Cloudflare Workers and Fastly Compute@Edge bet on Wasm for the edge layer is a serious commitment by serious infrastructure companies.
Whether Wasm replaces containers, augments them, or opens an entirely new niche for lightweight edge compute: the answer is all three for different use cases. The technology is too useful and too well-designed to stay only in the browser, and the momentum behind WASI and the Component Model suggests the server-side story will keep growing.
Solomon Hykes was not wrong. The implications of running sandboxed, portable, fast binary code anywhere is genuinely significant. The only question is how fast the ecosystem matures around it.
