WebAssembly
Low-level compiled browser compute, high-performance module integration, and worker-based message communication.
1 / Near-Native Browser Performance
WebAssembly entered my work through a specific requirement: running the Stockfish 16 chess engine — a C++ binary — directly in the browser for CheckMate. Server-side evaluation would have created unacceptable latency and infrastructure costs under concurrent user load. Compiling Stockfish to WASM allowed the engine to execute at near-native speed within the user's browser thread.
2 / Web Worker Integration
Running a CPU-intensive chess engine on the main browser thread would freeze the React UI. The solution was executing the WASM module inside a Web Worker, communicating UCI commands and evaluation results through message posting between the worker and the main thread. SharedArrayBuffer enabled low-overhead memory sharing, but required specific server headers — Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy — that added deployment configuration complexity.
3 / What I Learned
WebAssembly is not a general-purpose web technology in the way React or TypeScript are. It is a targeted solution for computation-heavy workloads that cannot be efficiently expressed in JavaScript. My experience is narrow but deep — the CheckMate project taught me about WASM module initialization, memory management across the JS-WASM boundary, and the practical constraints of running compiled binaries in a browser sandbox.