Top 10 WebAssembly Projects You Should Know About

The best way to understand what WebAssembly is capable of is to look at what people are building with it. The following ten projects span the spectrum from performance-critical rendering engines to full language runtimes, from indie libraries to products used by tens of millions of people. Each one pushes the limits of what the web platform can do.

1. Figma — Collaborative Design at 60 fps

Figma is the most widely cited real-world success story for WebAssembly, and for good reason. The core rendering engine — responsible for every bezier curve, gradient, and layout calculation — is written in C++ and compiled to Wasm via Emscripten.

Before Wasm, Figma's original asm.js build was slow and memory-constrained. The Wasm version loads 3× faster, uses memory more efficiently, and renders complex documents at a consistent 60 fps in the browser. More importantly, the Wasm binary is identical across platforms: the same code runs in Chrome, Firefox, Safari, and the Electron desktop app. Figma's engineering blog has detailed write-ups on how they structure the JS/Wasm boundary — a required reading for anyone building a performance-critical web application.

2. Google Earth — Terabytes of Terrain in the Browser

Google Earth's web version (earth.google.com) uses WebAssembly to run the same C++ geometry and terrain-rendering code that powers the native applications. The Wasm module handles 3D mesh streaming, terrain decoding, and the physics of camera movement — all at near-native speed.

What makes this impressive is the scale of the data: Earth streams terabytes of satellite imagery and elevation data in real time, decoded and rendered entirely in the browser without a plugin. The JavaScript side handles UI, authentication, and network orchestration; the Wasm side handles everything compute-intensive. It's a textbook example of the right division of labor.

3. SQLite Wasm — The World's Most Deployed Database, in the Browser

The SQLite team officially released SQLite Wasm in 2022 as the canonical way to run SQLite in browsers and other JavaScript environments. It compiles the full SQLite C source via Emscripten and exposes both a synchronous API (using SharedArrayBuffer and Atomics) and an asynchronous Promise-based API for environments without shared memory.

import { createSQLiteThread } from '@sqlite.org/sqlite-wasm'
 
const sqlite3 = await createSQLiteThread({ print: console.log })
 
await sqlite3('open', { filename: ':memory:' })
await sqlite3('exec', {
  sql: `CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT);
        INSERT INTO users VALUES (1, 'Alice'), (2, 'Bob');`,
})
 
const result = await sqlite3('exec', {
  sql: 'SELECT * FROM users',
  returnValue: 'resultRows',
  rowMode: 'object',
})
 
console.log(result.result.resultRows)
// [{ id: 1, name: 'Alice' }, { id: 2, name: 'Bob' }]

The official Wasm build can use the Origin Private File System (OPFS) API for persistent, high-performance storage — bypassing IndexedDB entirely. It's the foundation of several local-first web applications and powers the storage layer in products like Notion's offline mode.

4. ffmpeg.wasm — Full Media Processing in the Browser

ffmpeg.wasm is a complete port of ffmpeg — the most capable open-source media processing toolkit in existence — to WebAssembly. It runs entirely client-side, meaning video transcoding, audio extraction, GIF generation, and format conversion happen on the user's device without uploading anything to a server.

import { FFmpeg } from '@ffmpeg/ffmpeg'
import { fetchFile } from '@ffmpeg/util'
 
const ffmpeg = new FFmpeg()
await ffmpeg.load()
 
// Write input file to Wasm virtual filesystem
await ffmpeg.writeFile('input.mp4', await fetchFile(videoFile))
 
// Transcode to WebM
await ffmpeg.exec(['-i', 'input.mp4', '-c:v', 'libvpx-vp9', 'output.webm'])
 
// Read result
const data = await ffmpeg.readFile('output.webm')
const url  = URL.createObjectURL(new Blob([data.buffer], { type: 'video/webm' }))

The trade-off is size: the base Wasm binary is ~30 MB (though a trimmed "core" build is ~8 MB). But for applications that need real media processing without a backend, it's irreplaceable.

5. Pyodide — CPython in the Browser

Pyodide is a port of CPython 3.11 to WebAssembly, complete with NumPy, Pandas, Matplotlib, scikit-learn, and over 100 other scientific Python packages. It powers Jupyter Lite (JupyterLab running entirely in the browser with no server), Observable's Python notebooks, and dozens of educational coding environments.

# This runs in the browser — no server, no Python installation
import numpy as np
import matplotlib.pyplot as plt
 
x = np.linspace(0, 2 * np.pi, 100)
y = np.sin(x)
 
plt.plot(x, y)
plt.title('sin(x) rendered in the browser via Pyodide + Matplotlib')
plt.savefig('plot.png')

Pyodide bridges the Python and JavaScript worlds bidirectionally: Python code can call JavaScript APIs (including the DOM), and JavaScript code can call Python functions and inspect Python objects. With the arrival of Wasm GC in Chrome 119, future versions of Pyodide can use the browser's own GC instead of CPython's reference-counted heap.

6. Blazor WebAssembly — .NET in the Browser

Microsoft's Blazor WebAssembly runs the .NET 8 runtime entirely in the browser as a Wasm binary. C# developers can build full SPA applications with component-based UI, sharing model and validation code between client and server.

The .NET 8 release added AOT compilation: instead of interpreting IL bytecode, the .NET runtime can compile C# directly to Wasm at publish time, dramatically reducing startup latency. Applications that once took several seconds to load now start in under a second. It's the most complete demonstration of Wasm GC and multi-threading in a production framework.

7. WasmEdge — Cloud-Native AI Inference at the Edge

WasmEdge (a CNCF sandbox project) is a lightweight Wasm runtime optimized for cloud-native and AI workloads. Its WASI-NN extension exposes TensorFlow Lite, PyTorch, OpenVINO, and ONNX backends to Wasm modules — meaning you can run ML inference inside a sandboxed Wasm module with no native code escaping the sandbox.

WasmEdge integrates directly with containerd, allowing Kubernetes clusters to schedule Wasm workloads as first-class container equivalents. Docker Desktop ships WasmEdge support out of the box. It's the runtime of choice for serverless AI inference pipelines where isolation and portability matter as much as performance.

8. Emscripten — The Original Wasm Toolchain

No list of important Wasm projects would be complete without Emscripten. It predates WebAssembly itself (it originally targeted asm.js) and remains the most capable toolchain for porting large C and C++ codebases to the web.

Emscripten's real value is its POSIX emulation layer: it provides Wasm-compatible implementations of pthreads, setjmp/longjmp, dynamic linking, file I/O via a virtual filesystem, OpenGL via WebGL translation, and SDL2. Projects like SQLite Wasm, ffmpeg.wasm, and Google Earth all rely on Emscripten. Despite being over a decade old, it's actively maintained and added WASI output support in version 3.x.

9. wasm-pack + wasm-bindgen — The Rust/Wasm Ecosystem

The wasm-bindgen / wasm-pack duo is what makes Rust the most ergonomic language for browser-targeted Wasm development. wasm-bindgen generates JavaScript bindings from annotated Rust code with zero hand-written glue:

use wasm_bindgen::prelude::*;
 
#[wasm_bindgen]
pub struct Point {
    pub x: f64,
    pub y: f64,
}
 
#[wasm_bindgen]
pub fn distance(a: &Point, b: &Point) -> f64 {
    ((a.x - b.x).powi(2) + (a.y - b.y).powi(2)).sqrt()
}

wasm-pack build --target web

This produces a ready-to-import npm package with TypeScript definitions. Consumers use it exactly like any other npm module — no WebAssembly API boilerplate required. The ecosystem built on top of these two crates (Yew, Leptos, Trunk) makes Rust a viable full-stack web language.

10. Spin — The Serverless Wasm Framework

Fermyon's Spin is the most developer-friendly framework for building and deploying Wasm-based serverless applications. It handles the boilerplate of WASI, HTTP triggers, key-value stores, SQL databases, and outbound HTTP — letting you focus on writing handlers in Rust, Go, Python, TypeScript, or any WASI-compatible language.

Spin's combination of Wasmtime's security model, the Component Model's composability, and a one-command deploy to Fermyon Cloud makes it the closest equivalent to "Vercel for Wasm." If you want to explore serverless Wasm without managing infrastructure, Spin is the fastest on-ramp.

These ten projects span a remarkable range: desktop-class rendering, scientific computing, media processing, serverless infrastructure, and full language runtimes. What they share is a reliance on WebAssembly's core properties — performance, portability, and isolation — to do things that simply weren't possible in a browser or serverless environment before. The question is no longer whether Wasm can handle serious workloads; it's which workload you're going to tackle with it next.