A binary module can keep selected compute near the user, but it does not erase download time, memory copies, device limits, or the JavaScript boundary. This track follows a document-review tool that reads a user-selected image, extracts a local measurement, and discards the bytes when the task ends. The lessons separate module loading from memory ownership, main-thread responsiveness, and capability policy. They also show where a server or plain JavaScript path remains simpler. A module receives only capabilities the host supplies; application permissions still belong to the host.
Topics in this track
- Wasm Loading, Artifact, and Fallback Contract — Load a versioned module only when the workflow needs it and retain a usable fallback.
- Wasm Linear Memory, Ownership, and Copy Cost — Make byte ownership, allocation limits, and view invalidation visible at the JavaScript boundary.
- Wasm Worker Jobs, Cancellation, and Result Order — Run expensive modules off the main thread with bounded queues and stale-result protection.
- Wasm Capabilities, Isolation, and Performance Budget — Keep module authority narrow and require measured benefit before adding shared-memory complexity.
Prerequisite paths
Browser Execution and Resource Lifecycle; Offline and Device Capabilities.
Neighbor track
WebRTC and Peer Media Sessions.
Practice path
Build Project: bounded local scan analysis and check decisions in Web Development: browser compute and peer sessions quiz.