WebAssembly and Browser Platform Vocabulary for Web Developers

WebAssembly and the Modern Browser Platform

The browser is no longer just a JavaScript runtime. WebAssembly (WASM) has expanded what browsers can do — enabling near-native performance for compute-intensive applications, porting desktop software to the web, and running languages like Rust, C++, and Go in the browser. Alongside WASM, the browser platform has gained powerful capabilities through Service Workers, Progressive Web Apps, and performance standards. If you work in frontend engineering, this vocabulary is essential.

WebAssembly Core Vocabulary

Module

A WASM module is the compiled, distributable binary file (.wasm) containing WebAssembly code. It is analogous to a shared library or compiled object file. “We compile our image processing library to a WASM module that is loaded on demand when the user activates the editor.”

Instantiation

Instantiation is the process of creating a running instance of a WASM module in the browser. Instantiation involves allocating memory, linking imports, and initialising the module’s state. It is an asynchronous operation.

“The WebAssembly.instantiateStreaming() API combines fetching and instantiation into a single step for optimal performance.”

Linear Memory

Linear memory is the contiguous block of memory that a WASM module has access to. It is represented as an ArrayBuffer and can be read and written from both the WASM module and JavaScript code. Crucially, WASM does not have access to the DOM or browser APIs directly — data must be passed through linear memory.

“To pass a string from JavaScript to a WASM function, you write the string bytes into linear memory and pass the pointer and length as integer arguments.”

Import and Export

A WASM module can export functions and memory, making them callable from JavaScript. It can also import functions from JavaScript, allowing it to call back into the host environment.

“We export the processImage function from the WASM module and import a logError callback that the module calls when it encounters an unexpected state.”

Trap

A trap is a runtime error in WebAssembly — an unrecoverable error that immediately terminates execution of the module. Common causes include integer division by zero, out-of-bounds memory access, or an explicit unreachable instruction.

“The WASM module threw a trap when the input buffer was smaller than the expected minimum size — we added a bounds check in JavaScript before calling the function.”

Threads and Atomics

WASM threads require the SharedArrayBuffer and Atomics API. Shared memory enables multiple WASM instances to operate on the same memory, enabling parallelism.

“WASM threads are gated behind Cross-Origin Isolation headers, so you need to serve the page with COOP: same-origin and COEP: require-corp to enable them.”

Browser Platform Vocabulary

Service Worker

A Service Worker is a JavaScript file that the browser runs in a background thread, separate from the web page. It acts as a programmable network proxy, enabling offline support, background sync, and push notifications.

“The Service Worker intercepts all fetch requests and serves cached responses when the network is unavailable, making the app function offline.”

Cache API — the storage mechanism used by Service Workers to store request-response pairs for offline use.

Lifecycle events — install, activate, and fetch are the primary events a Service Worker handles. “During the activate event, we delete old cache versions to reclaim storage.”

Progressive Web App (PWA)

A PWA is a web application that uses Service Workers, a Web App Manifest, and HTTPS to provide an app-like experience — including installation on the home screen, offline support, and push notifications.

Web App Manifest — a JSON file (manifest.json) that provides metadata about the PWA: its name, icons, colours, and display mode. “Without a valid Web App Manifest, the browser will not offer the install prompt.”

Core Web Vitals

Core Web Vitals are Google’s standardised set of performance metrics that measure real-world user experience. They directly affect search ranking.

• LCP (Largest Contentful Paint) — the time until the largest visible element is rendered. Target: under 2.5 seconds.
• INP (Interaction to Next Paint) — the latency of interactions (click, tap, keyboard) from user input to visual response. Target: under 200ms. This replaced FID in 2024.
• CLS (Cumulative Layout Shift) — the visual stability of the page, measured as the total amount of unexpected layout shift. Target: below 0.1.

“Our LCP score degraded after the hero image was changed to a larger format — we resolved it by adding a <link rel="preload"> for the image.”

Five Example Sentences

1. “The WASM module exports a single encode function; JavaScript passes the input data through linear memory and reads the output from the same buffer after the call returns.”
2. “A trap was thrown during testing because the WASM code attempted to read beyond the bounds of the allocated linear memory — the root cause was an off-by-one error in the pointer arithmetic.”
3. “The Service Worker’s fetch handler checks the cache first and falls back to the network, ensuring the app remains functional in areas with poor connectivity.”
4. “After implementing a Web App Manifest and Service Worker, the install prompt appeared automatically on Android Chrome, and our PWA installs increased by 34% in the first month.”
5. “The CLS regression was caused by late-loading web font causing a layout reflow — fixing it required adding font-display: swap and reserving space for the text element.”

Staying Current

WebAssembly is evolving through a series of proposals — threads, SIMD, component model, garbage collection. The WASM specification proposals repository on GitHub is the primary reference for upcoming features. The Core Web Vitals metrics are updated periodically by Google — the Chromium blog and web.dev are authoritative sources for the latest thresholds and guidance.