Build fluency in the vocabulary of running compiled code at near-native speed in the browser and beyond.
0 / 5 completed
1 / 5
At standup, a dev mentions running compiled code from a language like Rust or C++ directly in the browser at near-native speed, alongside the page's JavaScript. What technology enables this?
WebAssembly, or Wasm, is a compact binary instruction format that lets code compiled from a language like Rust or C++ run in the browser at near-native speed, executing alongside the page's regular JavaScript. This makes performance-intensive tasks, like image processing or a physics simulation, practical to run directly in the browser without relying on a much slower interpreted JavaScript implementation. It's designed to be a portable compilation target rather than a language itself.
2 / 5
During a design review, the team wants their Wasm module to call a JavaScript function to access something Wasm alone can't reach directly, like the DOM. Which capability supports this?
JavaScript-to-Wasm interoperability bindings let a WebAssembly module call out to a JavaScript function to access something outside Wasm's own sandboxed capabilities, like manipulating the DOM or making a network request. Wasm intentionally runs in an isolated, sandboxed environment with no direct access to browser APIs on its own. These bindings bridge that gap, letting the two execution environments work together rather than requiring the same logic to be duplicated separately in each.
3 / 5
In a code review, a dev notices the team is running a Wasm module outside the browser entirely, in a lightweight, sandboxed server-side runtime. What does this represent?
Server-side WebAssembly execution runs a Wasm module outside the browser entirely, in a lightweight, sandboxed server-side runtime, taking advantage of Wasm's portability and strong sandboxing for a use case like a plugin system or edge computing function. This extends Wasm well beyond its original browser-focused design into a general-purpose, portable execution format. It's an increasingly common pattern for running untrusted or third-party code safely on a server.
4 / 5
An incident report shows a Wasm module was granted broader host system access than it actually needed, and a bug in the module accessed data outside its intended scope. What practice would prevent this?
Granting a Wasm module only the specific host capabilities it actually needs limits the potential impact if a bug or vulnerability in the module is triggered. Granting unrestricted access by default undermines the sandboxing benefit that's a core part of Wasm's design in the first place. This least-privilege capability model is an increasingly standard practice for server-side WebAssembly runtimes specifically designed around fine-grained permission control.
5 / 5
During a PR review, a teammate asks why the team compiles this performance-critical logic to WebAssembly instead of writing it directly in JavaScript. What is the reasoning?
A purely interpreted JavaScript implementation generally can't match the raw execution speed of compiled WebAssembly for computationally intensive logic, like complex numerical processing. WebAssembly's compact binary format executes at near-native speed, closing that performance gap significantly. The tradeoff is the added build complexity of compiling and integrating a separate Wasm module alongside the rest of the JavaScript codebase.