5 exercises — Practice WebAssembly vocabulary in English: binary format, WASI, component model, runtimes, host functions, instantiation, and serverless WASM.
Core WebAssembly vocabulary clusters
Format: binary format (.wasm), WAT (WebAssembly Text), module, section (type, function, memory, export, import)
Execution: stack machine, linear memory, sandbox, instantiation, exports, imports, host function
WASI: WebAssembly System Interface, capability-based security, wasi_unstable, wasi_preview1, wasi_preview2
A platform engineer introduces WebAssembly to a backend team exploring new runtimes: "WebAssembly — WASM — is a binary instruction format designed as a portable compilation target. Write once in Rust, C, C++, Go, or Python; compile to WASM; run anywhere: browser, server, edge, embedded. The key property: sandboxed execution. A WASM module can't access the filesystem, network, or system calls unless explicitly granted. The module declares imports (what it needs from the host) and exports (what it exposes to the host). The host provides the imports — full control over what the module can do." What is a host function in WebAssembly, and why is the import/export model central to WASM's security?
Host function: a function provided by the host environment that a WASM module can call via its imports. Examples: console.log in the browser (the browser implements it, WASM calls it), filesystem read in a WASI runtime (the runtime implements it, the module calls it). Import/export model: WASM module declares what it needs (imports) and what it provides (exports). The host controls which imports are satisfied. If the host doesn't provide a filesystem import, the module literally cannot read files — the sandbox is enforced at the VM level, not by operating system permissions. WASM module structure vocabulary: Module: the fundamental unit — a .wasm binary file. Instantiation: creating a runnable instance from a module + imports. Multiple instances from one module. Import: a function, memory, table, or global that the module requires from the host. Export: a function, memory, table, or global that the module exposes to the host. Linear memory: a contiguous, resizable byte array. The module's heap. Host can read/write it. Stack machine: WASM's execution model. Instructions push/pop values from a virtual stack. Different from a register machine. WAT (WebAssembly Text format): human-readable .wat format. Compiles to .wasm binary. Useful for debugging. In conversation: 'The sandbox is why we can run user-submitted WASM plugins safely. They declare their imports; we provide a restricted set. No file access, no network — just our plugin API.'
2 / 10
A systems engineer explains WASI to a developer building a CLI tool: "WASM in the browser has access to browser APIs. But to use WASM outside the browser — on a server, in a CLI — you need system interfaces: files, network, environment variables. WASI — WebAssembly System Interface — standardises these. A WASM module compiled with WASI support can read files, write to stdout, get environment variables — but only the capabilities explicitly granted to it. It's capability-based security: you get a handle to a specific directory, not the whole filesystem. wasmtime and Wasmer both implement WASI." What is capability-based security in WASI, and how does it differ from traditional OS permissions?
Capability-based security: access is controlled by possessing a capability (an unforgeable reference/handle). In WASI: instead of "module X has read access to /tmp" (POSIX-style permission check), you pass the module a directory handle (preopened directory). The module can only access that specific directory — it has no way to reference any other directory. vs. traditional POSIX: POSIX checks permissions by process identity (UID/GID). Any path can be accessed if the process has permission. WASI checks by handle possession — no handle = no access, regardless of identity. WASI vocabulary: WASI preview1 (wasi_snapshot_preview1): the first widely-deployed WASI ABI. Supported by most toolchains and runtimes. Includes: fd_read, fd_write, path_open, clock_time_get, random_get. WASI preview2: a redesigned WASI using the component model. Async-first, cleaner API. Preopened directory: a directory the host grants the module access to at startup. Module can navigate within it. wasmtime: production WASM runtime by Bytecode Alliance (Mozilla, Intel, Fastly). Implements WASI and component model. Wasmer: alternative runtime with focus on multiple backends. WasmEdge: focus on cloud-native and edge computing. WAMR (WebAssembly Micro Runtime): embedded/IoT focus, minimal footprint. In conversation: 'WASI + capability-based security is why WASM is attractive for plugin systems. You give the plugin a handle to its own storage directory and our API — nothing else. Compared to a subprocess with broad OS access, it's a massive security improvement.'
3 / 10
A developer explains the WebAssembly Component Model to a team evaluating it for a plugin system: "The original WASM module model has a problem: the only data you can pass between modules is numbers (i32, i64, f32, f64) and linear memory. If you want to pass a string, you copy bytes into memory and pass a pointer — very low-level. The Component Model adds a type system on top: strings, lists, records, variants, resources. WIT — WebAssembly Interface Types — is the IDL (Interface Definition Language) for defining component interfaces. Components can import and export high-level interfaces, and the toolchain generates the glue code." What is the purpose of WIT in the WebAssembly Component Model?
WIT (WebAssembly Interface Types): a text-based IDL for declaring component interfaces. Defines: functions (with typed parameters and returns), records (structs), variants (enums with data), resources (object handles with methods), interfaces (named groups of functions), worlds (the complete set of imports and exports for a component). From a WIT file, toolchains generate bindings in: Rust (wit-bindgen), Python, JavaScript, Go. Why needed? Without WIT, two WASM components written in different languages can only communicate through linear memory (raw bytes) — the caller must know the exact memory layout. WIT makes the interface explicit and typed, enabling automatic binding generation. Component model vocabulary: Component: a higher-level WASM container that has WIT-typed imports/exports. Composed of one or more core modules. World: the complete interface of a component — what it imports (needs) and exports (provides). Interface: a named group of functions and types in WIT. Composition: combining multiple components by wiring their imports/exports together. wit-bindgen: tool that generates language bindings from WIT files. wasm-compose: tool for composing WASM components. WASI component model: WASI preview2 is built on the component model. In conversation: 'WIT is to WASM components what Protobuf is to gRPC — a language-agnostic contract that generates code on both sides.'
4 / 10
A performance engineer explains AOT vs. JIT compilation for WASM runtimes: "WASM bytecode is portable but must be compiled to native machine code before execution. There are two approaches. JIT (Just-In-Time): compile during execution. Faster startup than full compile, but compilation happens at runtime. AOT (Ahead-Of-Time): compile before execution to a native binary. Wasmtime supports both. AOT is critical for serverless WASM — cold start latency with AOT-compiled modules can be under 1ms, versus tens of milliseconds for JIT. The trade-off: AOT produces platform-specific binaries (x86-64 Linux) — you lose portability." What is a cold start in the context of serverless WASM, and why is WASM attractive for this use case?
Cold start: in serverless functions, a cold start is the first invocation after the function instance has been deallocated (idle timeout). The runtime must: pull the function code, initialise the execution environment, start the runtime, and then run the function. Container cold start: 500ms to several seconds. Python Lambda: ~100ms. Node.js Lambda: ~50ms. WASM cold start: Cloudflare Workers (V8 isolates, similar model) and Fastly Compute (WASM) achieve <1ms cold starts. Why: WASM modules are small (kilobytes to low megabytes), instantiation is cheap (no OS process spawning), the sandbox model reuses a single runtime process with many isolated instances. Serverless WASM vocabulary: Cloudflare Workers: edge compute platform using V8 isolates (JavaScript/WASM). Sub-millisecond cold starts. Fastly Compute: serverless WASM using wasmtime. Fermyon Spin: microservices framework on wasmtime + WASI. WasmCloud: distributed WASM actor model. Isolate: a lightweight sandboxed execution context. Cheaper than a process or container. AOT precompilation: in Wasmtime, use wasmtime compile to produce a .cwasm file. Can be instantiated in <1ms. Instant-on: the ideal of zero cold start latency with fresh sandboxes per request. WASM approaches this more than any other portable execution model. In conversation: 'We migrated an API gateway middleware to WASM. Cold starts went from 40ms (Lambda cold start) to under 1ms. For high-traffic APIs with bursty patterns, that difference is material.'
5 / 10
A compiler engineer explains WASM in the context of cross-language interoperability: "The original promise of WASM: compile any language to a portable binary, run anywhere. Today: Rust to WASM is excellent. C/C++ via Emscripten is mature. Go compiles to WASM but produces large binaries. Python via Pyodide bundles the Python interpreter as WASM. The Component Model is the next step: instead of a single monolithic WASM binary, you compose components written in different languages. A Rust component providing a parsing library can be called by a Python component without FFI complexity — the runtime handles the interface." What is Emscripten and what role does it play in the WASM ecosystem?
Emscripten: a complete open-source toolchain targeting WebAssembly (and asm.js). Uses LLVM + Clang as the compiler backend. Key feature: system library emulation. Emscripten implements POSIX functions (file I/O, pthreads, sockets) using browser or Node.js APIs. Real-world use: Figma (C++ render engine → WASM), Google Earth (C++ → WASM), AutoCAD Web (C++ → WASM), SQLite (compiled to WASM for browser use). Compile chain vocabulary: LLVM: compiler infrastructure. Clang compiles C/C++ to LLVM IR; LLVM emits WASM. wasm-pack: tool for building Rust-generated WASM for browser use. Generates npm package. wasm-bindgen: Rust library for calling JavaScript from WASM and vice versa. Pyodide: CPython compiled to WASM. Runs Python in the browser. Includes NumPy, Pandas. wasi-sdk: SDK for compiling C/C++ to WASM + WASI (for server-side/CLI use). Alternative to Emscripten when targeting WASI instead of browser. Binary format vocabulary: .wasm: binary format. Compact, fast to parse. .wat: text format. Human-readable S-expressions. Custom sections: non-functional sections in the binary for debug info (DWARF), component model metadata. Module validation: WASM spec requires structural validation before execution — type safety guaranteed at the binary level. In conversation: 'Emscripten is how we ported 500K lines of C++ simulation code to the browser. The alternative was a rewrite — Emscripten saved 18 months of work.'
6 / 10
Code Review Comment: 'This module's using a lot of i32. Seems inefficient for floating-point calculations. Consider using f32 or f64 if appropriate to avoid potential truncation issues.' What does this comment *primarily* highlight regarding WASM modules?
The comment focuses on the potential for data loss when using i32 with floating-point operations. It's raising a concern about truncation – where integer values are converted to floats and lose precision. The correct answer reflects this core issue, not simply stating that all WASM modules use integers.
7 / 10
Slack Message: 'Hey team, I'm seeing some really high latency with our new CLI tool using WASM. It seems to be spending a lot of time in the WASI_Filesystem_Open call. Anyone have any insights?' What is the primary concern expressed in this message regarding the WASM runtime?
The message highlights high latency specifically associated with the WASI_Filesystem_Open call. This indicates that the problem likely lies in the interaction between the WASM runtime and the underlying file system interface – a common area for performance issues when using WASI.
8 / 10
PR Description: 'Adding support for WASI. This allows our service to interact with the host operating system's file system and network interfaces directly via the WASM runtime. The module uses WASI_Filesystem_Readlink to resolve symbolic links.' What is the key benefit of using WASI_Filesystem_Readlink in this context?
The core purpose of WASI_Filesystem_Readlink is to facilitate interaction with the host OS. By resolving symbolic links, it allows the WASM module to traverse the file system hierarchy – a fundamental capability provided by WASI.
9 / 10
Standup Update: 'I've been working on integrating Rust code into a WASM project. Initially, I was using the standard WASM module model, but it quickly became apparent that we needed a way to share data between modules beyond just integers. We are now exploring the Component Model as a solution.' What prompted the shift in approach described in this update?
The core issue driving the shift is the limitation of the original WASM module model – its restriction to passing only numerical data types. The developer identified this as a major impediment and sought a solution that would allow for richer data exchange between modules.
10 / 10
API Response: 'WASI_System_Exec returned an error code: ERR_NOT_FOUND. The command 'ls' was not found in the system's PATH.' What does this API response *primarily* indicate about the WASM runtime's interaction with the host OS?
The ERR_NOT_FOUND error signifies that the executable ('ls') could not be located within the system's PATH. This is a common issue when running external commands through WASI and highlights the runtime's reliance on the host OS to resolve command paths correctly.
What does the "WebAssembly Runtime Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to webassembly runtime vocabulary through 10 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 10 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 11 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.