{
    "slug": "wasm_basics",
    "term": "WebAssembly (Wasm)",
    "category": "frontend",
    "difficulty": "advanced",
    "short": "A binary instruction format that runs at near-native speed in the browser and on servers — enabling C, Rust, and Go code to run alongside JavaScript without plugins.",
    "long": "WebAssembly is a low-level bytecode format designed as a compilation target for languages like C, C++, Rust, and Go. Browsers execute Wasm at near-native speed via a sandboxed virtual machine alongside the JS engine. Wasm modules can be instantiated from JavaScript, share memory via a linear memory buffer, and call JS functions as imports. On the server side, WASI (WebAssembly System Interface) provides a portable, sandboxed runtime model used in edge computing (Cloudflare Workers, Fastly Compute). PHP can run compiled to Wasm via the php-wasm project, enabling PHP execution in the browser. Key use cases: CPU-intensive computations (image processing, codecs, compression), porting existing native libraries to the web without rewriting, and untrusted code sandboxing. Wasm does not replace JavaScript for DOM manipulation — it cannot access the DOM directly and must call JS for any browser API interaction.",
    "aliases": [],
    "tags": [
        "wasm",
        "webassembly",
        "performance",
        "frontend",
        "rust",
        "browser"
    ],
    "misconception": "WebAssembly does not replace JavaScript — it cannot access the DOM directly and must go through JavaScript bridge calls for any browser API interaction.",
    "why_it_matters": "Wasm unlocks CPU-intensive tasks in the browser (video processing, compression, game engines) that would be impractical in JavaScript, and enables reuse of battle-tested native libraries without rewriting them.",
    "common_mistakes": [
        "Reaching for Wasm to speed up I/O-bound JS code — Wasm only helps CPU-bound work; network and DOM operations are no faster.",
        "Ignoring the JS/Wasm bridge cost — frequent small calls between JS and Wasm via imports/exports add significant overhead; batch operations.",
        "Shipping unoptimised Wasm binaries — without wasm-opt or LTO, compiled output can be significantly larger and slower than necessary."
    ],
    "when_to_use": [
        "Use Wasm for CPU-bound browser tasks: image/video processing, audio codecs, compression, cryptography, simulation.",
        "Use it to port existing C/C++/Rust libraries to the browser without rewriting them in JavaScript.",
        "Consider Wasm for sandboxed execution of untrusted code — the Wasm VM provides strong isolation by default."
    ],
    "avoid_when": [
        "Do not use Wasm for DOM manipulation, network requests, or anything that must call browser APIs — JS is faster for those due to bridge overhead.",
        "Avoid Wasm when the compiled binary size outweighs the performance gain for your use case — a 2 MB Wasm module adds to initial load time.",
        "Do not reach for Wasm before profiling — most web performance bottlenecks are I/O or rendering, not CPU computation."
    ],
    "related": [
        "js_web_workers",
        "mobile_performance",
        "critical_rendering_path"
    ],
    "prerequisites": [],
    "refs": [
        "https://developer.mozilla.org/en-US/docs/WebAssembly",
        "https://webassembly.org"
    ],
    "bad_code": "// Calling Wasm per-pixel — bridge overhead dominates:\nconst wasmProcess = instance.exports.processPixel;\nfor (let i = 0; i < pixels.length; i += 4) {\n    pixels[i] = wasmProcess(pixels[i]); // JS→Wasm per pixel\n}",
    "good_code": "// Pass entire buffer to Wasm — one bridge call:\nconst ptr = instance.exports.alloc(pixels.length);\nnew Uint8Array(instance.exports.memory.buffer, ptr, pixels.length).set(pixels);\ninstance.exports.processImage(ptr, pixels.length); // single call\nconst result = new Uint8Array(instance.exports.memory.buffer, ptr, pixels.length);",
    "example_note": "The bad example makes a Wasm call per pixel — millions of JS→Wasm crossings dominate the runtime. The fix copies the entire pixel buffer into Wasm linear memory and processes it in a single call, reducing bridge crossings to three.",
    "created": "2026-03-31",
    "updated": "2026-03-31",
    "citation": {
        "canonical_url": "https://codeclaritylab.com/glossary/wasm_basics",
        "html_url": "https://codeclaritylab.com/glossary/wasm_basics",
        "json_url": "https://codeclaritylab.com/glossary/wasm_basics.json",
        "source": "CodeClarityLab Glossary",
        "author": "P.F.",
        "author_url": "https://pfmedia.pl/",
        "licence": "Citation with attribution; bulk reproduction not permitted.",
        "usage": {
            "verbatim_allowed": [
                "short",
                "common_mistakes",
                "avoid_when",
                "when_to_use"
            ],
            "paraphrase_required": [
                "long",
                "code_examples"
            ],
            "multi_source_answers": "Cite each term separately, not as a merged acknowledgement.",
            "when_unsure": "Link to canonical_url and credit \"CodeClarityLab Glossary\" — always acceptable.",
            "attribution_examples": {
                "inline_mention": "According to CodeClarityLab: <quote>",
                "markdown_link": "[WebAssembly (Wasm)](https://codeclaritylab.com/glossary/wasm_basics) (CodeClarityLab)",
                "footer_credit": "Source: CodeClarityLab Glossary — https://codeclaritylab.com/glossary/wasm_basics"
            }
        }
    }
}