Start Here
WebAssembly AI Atlas connects two bodies of knowledge that are often learned separately: how portable code executes and how inference systems move tensors through models and hardware. You do not need to master every prerequisite before starting, but you must know which layer you are reasoning about.
Recommended background
- Low-Level Atlas I for C, memory, assembly, linking, processes, and concurrency fundamentals.
- Low-Level Atlas II for building executable systems, parsers, servers, and storage components from first principles.
- Low-Level Atlas III for browser/server boundaries, protocols, workers, backpressure, and concurrent systems.
- AI Atlas for tensors, neural networks, LLMs, embeddings, RAG, agents, evaluation, and inference optimization.
You can begin with gaps, but follow links back to those Atlas projects instead of rebuilding their full theory here.
Platform roles
| Environment | Role in this Atlas |
|---|---|
| Browser | Primary host, UI, storage, media, lifecycle, and capability boundary |
| WebAssembly | Portable CPU execution and sandboxed guest code |
| WebGPU | Explicit GPU compute and buffer management |
| WebNN | High-level neural graph API targeting CPU, GPU, or NPU when supported |
| WASI | Portable host interfaces outside the browser |
| JavaScript / TypeScript | Host orchestration and the main Workbench application |
| Rust | Primary language for new Wasm modules and components |
| C / C++ | Porting, Emscripten, and toolchain comparison |
| Python | Training/export reference and golden-output generation |
WebAssembly, WebGPU, WebNN, and WASI are complementary, not interchangeable. A runtime may use Wasm on CPU, call WebGPU, expose WebNN, or provide WASI-NN; each path has a different API, authority model, compatibility surface, and cost profile.
What you will build over time
WasmAI Workbench starts with a hand-written WAT vector module, grows into a tiny tensor and MLP inference engine, compares scalar/SIMD/threaded kernels, loads real ONNX and LiteRT artifacts, selects accelerated backends, works offline for image and audio tasks, adds retrieval-first semantic search, packages a portable component, and finally hosts typed tools inside capability-limited Wasm sandboxes.
This skeleton documents the route. The runnable artifacts arrive with future atomic notes and must compile or execute exactly as documented.
Two valid reading routes
Linear route
Read Orientation, then phases 01 through 06 in order. Keep Always Active open while building every milestone.
Project route
Choose a Workbench milestone, open its phase page, and follow the prerequisite branches backward until every byte, tensor shape, capability, and backend decision is understood. Do not jump directly to a runtime API if you cannot yet explain its memory and model contracts.
Before using hardware-specific features
- Treat browser support as dated evidence, not a permanent fact.
- Expect WebGPU, WebNN, SIMD, threads, and cross-origin isolation to differ by environment.
- Keep small CPU/Wasm baselines so accelerated paths can be verified and fall back visibly.
- Use small models and deterministic fixtures before measuring large workloads.
- Record numerical tolerances; equal-looking labels are not proof of equivalent tensors.
First loop
- Read Must Know.
- Establish the evidence rules in Phase 00: Orientation.
- Enter WebAssembly Execution Model.
- Keep Performance, Security & Craftsmanship active from v0.
- Use Reference Registry whenever a specification or API status can change.