# WebAssembly

> Source: https://aiwiki.ai/wiki/webassembly
> Updated: 2026-06-24
> Categories: AI Infrastructure, Software Development
> From AI Wiki (https://aiwiki.ai), a free encyclopedia of artificial intelligence. Quote with attribution.

**WebAssembly** (often abbreviated **Wasm**) is a binary instruction format for a stack-based virtual machine, designed as a portable compilation target for high-level programming languages and intended to enable deployment on the web for client and server applications. It executes at near-native speed by taking advantage of common hardware capabilities while running inside a sandboxed environment, and it is supported as an open web standard by all major browsers alongside HTML, CSS, and [JavaScript](/wiki/javascript). The W3C published WebAssembly 1.0 as an official Recommendation on December 5, 2019, describing it as a "safe, portable, low-level format designed for efficient execution and compact representation of code on modern processors including in a web browser," and making it the fourth language to run natively in browsers after HTML, CSS, and JavaScript. [1] As of 2025, support reaches roughly 96% of global browser sessions. [21]

Wasm originated as a cross-vendor effort coordinated through the World Wide Web Consortium (W3C) in 2015 and shipped its minimum viable product (MVP) in March 2017 in the four major browser engines. The format was created so that languages such as C, [C++](/wiki/c_plus_plus), and [Rust](/wiki/rust) could run on the web with predictable performance, and so that the same compiled artifacts could later run on servers, edge nodes, embedded devices, and inside other host environments.

For artificial intelligence and machine learning, Wasm has become a critical piece of in-browser and edge inference infrastructure. Projects such as Hugging Face's [Transformers.js](/wiki/transformers_js), the [ONNX](/wiki/onnx) Runtime Web, the [TensorFlow.js](/wiki/tensorflow_js) Wasm backend, and the MLC team's [WebLLM](/wiki/webllm) all rely on WebAssembly, often combined with [WebGPU](/wiki/webgpu), to run neural networks and large language models entirely on the client. WebLLM, evaluated on an Apple MacBook Pro M3 Max, reports retaining "up to 80% native performance on the same device" when using WebGPU together with JavaScript and Wasm. [10] On the server side, edge platforms operated by [Cloudflare](/wiki/cloudflare), [Fastly](/wiki/fastly), Vercel, Shopify, and Fermyon use WebAssembly runtimes to host user-supplied AI inference and agent code in fast-starting, isolated sandboxes.

## Infobox

| Field | Value |
|---|---|
| Designed by | W3C WebAssembly Working Group / Community Group |
| Initial release | March 2017 (MVP shipped in major browsers) |
| W3C Recommendation (1.0) | December 5, 2019 |
| WebAssembly 2.0 | Completed March 20, 2025; became a W3C standard in December 2024 |
| WebAssembly 3.0 | Completed September 17, 2025 |
| File extensions | .wasm (binary), .wat (text) |
| Format | Binary instruction format for a stack-based virtual machine |
| Influences | asm.js, Google Native Client (NaCl/PNaCl) |
| Standard | W3C Recommendation; open web standard |
| License | Open standard (no royalties) |
| Major implementations | V8, SpiderMonkey, JavaScriptCore, Wasmtime, Wasmer, WAMR, WasmEdge, Wazero, wasm3 |
| Website | webassembly.org |

## History

### Predecessors

The direct predecessors of WebAssembly were two earlier attempts to give the browser a high-performance code path beyond ordinary JavaScript. Google's Native Client (NaCl) and its portable variant PNaCl, first announced in 2011 and shipped in Chrome, allowed C and C++ code to execute inside a browser sandbox at close to native speed, but the technology was Chrome-only and never gained cross-vendor adoption. In 2013, [Mozilla](/wiki/mozilla) engineers introduced asm.js, a strict subset of JavaScript that could be compiled ahead of time by the engine and used as a target for compiling C and C++ programs through Emscripten. Asm.js demonstrated that high-performance native code could run in any browser with no new download format, but it inherited the parsing cost of JavaScript and was bound by the language's text representation.

### Cross-vendor agreement

In April 2015 the WebAssembly Community Group was created at the W3C, and the project's design repository was opened with initial commits by Mozilla engineer Luke Wagner. On June 17, 2015, [Google](/wiki/google), [Apple](/wiki/apple), [Microsoft](/wiki/microsoft), and Mozilla publicly announced cross-vendor agreement on the new format, with each browser team posting linked blog announcements the same day. Brendan Eich, the creator of JavaScript, summarized the announcement in a widely shared post titled "From ASM.JS to WebAssembly," framing Wasm as "a new binary syntax for low-level safe code, initially co-expressive with asm.js, but in the long run able to diverge from JS's semantics." [4] Throughout 2016 the four engine teams iterated on a Browser Preview that exercised compatibility across V8, SpiderMonkey, JavaScriptCore, and Chakra.

### When was WebAssembly released?

On February 28, 2017, the four browser vendors declared cross-engine consensus that the MVP was complete. Firefox 52 shipped support on March 7, 2017, followed by Chrome 57 on March 9, 2017. Safari 11 (released September 19, 2017) and Edge 16 (October 31, 2017) added support later that year, completing browser-wide availability. The MVP defined the core instruction set, the linear memory model, the binary and text formats, and the JavaScript embedding API. [5]

W3C standardization continued in parallel. On December 5, 2019, the WebAssembly Core Specification, the JavaScript Interface, and the Web API specifications were jointly published as W3C Recommendations, formally making WebAssembly 1.0 an official web standard alongside HTML, CSS, and JavaScript. Philippe Le Hegaret, the W3C project lead, said at the time that "the arrival of WebAssembly expands the range of applications that can be achieved by simply using Open Web Platform technologies." [1]

### Beyond the browser

In November 2019, Mozilla, Fastly, Intel, and Red Hat announced the formation of the [Bytecode Alliance](/wiki/bytecode_alliance), a vendor-neutral organization aimed at building secure runtimes and tooling for WebAssembly outside the browser. Founding contributions included [Wasmtime](/wiki/wasmtime), the WebAssembly Micro Runtime (WAMR), and the Cranelift code generator. [6] The alliance later expanded to include Microsoft, Amazon, Arm, Google, Siemens, and others, and incorporated as a 501(c)(6) industry consortium.

### Post-1.0 evolution

After 1.0, the W3C WebAssembly Working Group accepted a steady stream of proposals through a multi-phase process. Features that have shipped widely include 128-bit fixed-width SIMD (v128), threads with shared memory and atomics, exception handling, multi-value returns, bulk memory operations, reference types and tail calls, and a typed garbage collection (GC) extension that reached cross-engine support in 2023. The WebAssembly 2.0 specification, which incorporates these post-1.0 features, was finished in 2022 and became a W3C standard in December 2024; the working group announced its completion on the WebAssembly project blog on March 20, 2025. [7]

WebAssembly 3.0 was completed and published on September 17, 2025. The project blog described it as "a substantially larger update: several big features, some of which have been in the making for six or eight years, finally made it over the finishing line." [8] Wasm 3.0 adds a 64-bit address space (Memory64) that expands the addressable space of a Wasm application from 4 gigabytes to a theoretical 16 exabytes (capped at 16 gigabytes on the web), the ability for a single module to declare and access multiple memories, garbage collection, typed function references, tail calls, exception handling, and relaxed (implementation-dependent) variants of the SIMD vector instructions. [8]

## Design and architecture

WebAssembly defines a stack-based virtual machine that operates over a small number of value types and a flat, byte-addressable linear memory. Programs are organized as modules, each of which declares its imports, exports, functions, tables, memories, globals, and data and element segments. Modules are validated by the host before execution to guarantee type and memory safety, and each module instance runs in a sandbox separated from the host process and from other instances.

### Value types and instructions

The core value types are i32 and i64 for 32-bit and 64-bit integers, f32 and f64 for IEEE 754 single- and double-precision floats, the v128 type added by the SIMD proposal for 128-bit packed vectors, and reference types such as funcref and externref. Instructions consume operands from a virtual stack and push results back, mirroring the structure of typed bytecode formats. Control flow uses structured constructs (block, loop, if, br, br_if, br_table, return, call, call_indirect) rather than arbitrary jumps, which makes single-pass validation and streaming compilation straightforward.

### Linear memory and tables

Each module may declare one or more linear memories, which are contiguous, resizable arrays of bytes addressed by 32-bit indices in the original specification. The Memory64 proposal, finalized in Wasm 3.0, extends addressing to 64 bits for hosts that need it. Tables hold opaque references such as function pointers; the call_indirect instruction performs type-checked dispatch through a table entry, providing a safe substitute for raw function pointers in the source language.

### Binary and text formats

The binary format (.wasm) is a compact, length-prefixed encoding designed for fast streaming compilation, with sections for types, imports, functions, tables, memories, globals, exports, the start function, elements, code, data, and an optional name section that aids debugging. The text format (.wat) uses S-expressions and is intended for human readers and tooling rather than as a deployment format. Tools such as wabt, wat2wasm, and binaryen convert between the two.

### Validation and execution

Wasm modules are validated in a single pass before they execute. The validation rules guarantee that the program is well-typed at every stack position, that memory and table accesses are bounds-checked, and that control flow is structured. Engines compile the validated module either ahead of time, just in time, or with a tiered combination of the two. Because the bytecode is already low-level and typed, engines avoid much of the speculative optimization machinery that JavaScript JITs require, which gives Wasm consistent performance without a long warmup curve. [2]

### Embedding

WebAssembly itself does not specify any I/O, DOM access, networking, or filesystem. Instead, host environments expose capabilities through imports. In a [web browser](/wiki/web_browser), the JavaScript Interface and Web API specifications define how Wasm modules interact with the page; on a server, the host might supply WebAssembly System Interface (WASI) APIs or a custom set. This separation lets the same .wasm artifact run in different hosts with the same execution semantics.

## How does WebAssembly compare to JavaScript on performance?

The headline goal of WebAssembly is to deliver predictable, near-native performance in a portable, sandboxed format. In practice the runtime cost of the sandbox (bounds checks on memory accesses, indirect call validation, stack overflow checks, and the abstraction layer between Wasm types and host machine types) places a ceiling on how close Wasm can get to hand-tuned native code. Benchmarks published by browser engine teams and academic studies typically place Wasm within roughly a small constant factor of native C, with the gap depending heavily on the workload, the toolchain, and whether SIMD and threads are used.

Compared with JavaScript, Wasm has two practical performance advantages. First, the binary format is fast to parse and validate, and engines can begin compiling the moment bytes arrive over the network, so startup is fast. Second, Wasm has no dynamic typing, no hidden classes, and no inline cache machinery, so once compiled, performance is steady and does not depend on speculative warmup. JavaScript JITs can match or exceed Wasm on numeric microbenchmarks once they have warmed up, but Wasm wins on consistency and on workloads that resist speculative optimization, such as compression, cryptography, image and video processing, physics, and machine learning kernels.

## Languages targeting WebAssembly

A broad ecosystem of languages and toolchains can produce .wasm modules. The table below summarizes the most established options.

| Language | Toolchain | Notes |
|---|---|---|
| C / C++ | Emscripten, clang with the wasm32 target | The original target audience for Wasm; mature support including SDL ports, OpenGL via WebGL, and POSIX shims. |
| Rust | rustc with wasm32-unknown-unknown, wasm32-wasi, wasm-bindgen | First-class support; popular for browser libraries and edge functions. |
| Go | Mainline gc compiler (GOOS=js, wasm and GOOS=wasip1), TinyGo | TinyGo produces much smaller binaries and is preferred for size-sensitive workloads. |
| AssemblyScript | AssemblyScript compiler (asc) | A TypeScript-like language designed specifically for Wasm. |
| C# / .NET | Blazor WebAssembly, .NET Wasm SDK | Runs the .NET runtime in the browser; used by Microsoft Blazor. |
| Swift | SwiftWasm community toolchain | Experimental but functional. |
| Zig | Zig compiler with wasm32-freestanding or wasm32-wasi | Built-in cross-compilation to Wasm. |
| [Python](/wiki/python) | Pyodide (CPython compiled with Emscripten), Wasmer Py | Used in JupyterLite and Cloudflare Python Workers. |
| Ruby | ruby.wasm | Official Ruby builds compiled to Wasm. |
| Java / JVM | CheerpJ, TeaVM, JWebAssembly | Run Java applets and applications in the browser without a JVM plugin. |
| Kotlin | Kotlin/Wasm | Official Kotlin Wasm backend with GC support. |
| [TypeScript](/wiki/typescript) | AssemblyScript or via JavaScript transpilation | Direct TS-to-Wasm via AssemblyScript subset; full TS via JS bridge. |

## Runtimes outside the browser

The browser engines V8 (Chrome, Edge, [Node.js](/wiki/nodejs), [Deno](/wiki/deno), [Bun](/wiki/bun)), SpiderMonkey (Firefox), and JavaScriptCore (Safari) all ship Wasm engines, but a parallel ecosystem of standalone runtimes has grown up around server-side, edge, and embedded use cases.

| Runtime | Maintainer | Implementation language | Typical use |
|---|---|---|---|
| Wasmtime | Bytecode Alliance | Rust | General-purpose server and CLI host; reference implementation for WASI. |
| [Wasmer](/wiki/wasmer) | Wasmer, Inc. | Rust | Commercial-friendly runtime with multiple compiler backends (Cranelift, LLVM, Singlepass). |
| WAMR (WebAssembly Micro Runtime) | Bytecode Alliance | C | Embedded and IoT devices; small footprint, interpreter and AOT modes. |
| WasmEdge | CNCF (Cloud Native Computing Foundation) | C++ | Edge and serverless workloads, AI inference extensions. |
| Wazero | Tetrate | Go | Pure Go runtime with no CGO; embeds easily in Go applications. |
| wasm3 | Community | C | Fast interpreter aimed at constrained embedded targets. |
| Lucet | Originally Fastly, now archived in favor of Wasmtime | Rust | Pioneered ahead-of-time Wasm compilation for edge computing. |

Several major commercial platforms run user code on top of WebAssembly:

| Platform | Underlying engine | Notes |
|---|---|---|
| Cloudflare Workers | V8 isolates with Wasm support since 2018 | JavaScript and Wasm guests share a process via V8 isolates; Python Workers use Pyodide compiled to Wasm. |
| Fastly Compute | Wasmtime (replaced the original Lucet runtime) | Each request runs in a fresh Wasm instance; cold start measured in tens of microseconds. |
| Vercel Edge Functions | V8 isolates | JavaScript, TypeScript, and Wasm modules executed at the edge. |
| Shopify Functions | Wasmtime | Customizable storefront and checkout logic supplied by merchants. |
| Fermyon Spin | Wasmtime | Open-source serverless framework focused on Wasm components. |
| Cosmonic / wasmCloud | Wasmtime via wasmCloud | Distributed application platform built on Wasm components. |

## WebAssembly System Interface (WASI)

The WebAssembly System Interface is a family of standardized APIs that lets Wasm modules interact with operating system facilities such as the filesystem, clocks, random number generation, environment variables, and (in newer revisions) sockets and HTTP. WASI was originally announced by Mozilla in 2019 and is now developed by a W3C subgroup with participation from the Bytecode Alliance and other vendors. [20]

WASI Preview 1 (sometimes called wasi_snapshot_preview1) defined a POSIX-like, capability-based API surface that quickly became the de facto standard for non-browser Wasm. Programs targeting WASI Preview 1 obtain capabilities (for example, a directory handle) from the host at instantiation rather than calling open() against a global filesystem; this restricts the blast radius of a misbehaving module.

WASI Preview 2, finalized in early 2024, is the first version built on top of the Component Model. Instead of a flat list of imports, Preview 2 organizes APIs into versioned interfaces described in WIT (the WebAssembly Interface Type language) and groups them into worlds. Specific interfaces include wasi:filesystem, wasi:cli, wasi:io, wasi:clocks, wasi:sockets, and wasi:http. The shift to the Component Model lets WASI evolve API by API rather than as a single monolithic import set.

## The Component Model

The Component Model is a layer above the core WebAssembly specification that allows modules written in different source languages to interoperate through well-typed interfaces rather than the raw integer-and-pointer ABI of core Wasm. It introduces:

- A higher-level type system (records, variants, lists, options, results, resources, and strings) that maps to idiomatic types in source languages.
- The WIT interface description language, used to declare interfaces and worlds.
- Canonical ABI rules that explain how component-level values lower to and lift from core Wasm.
- Component composition, which lets a final binary include multiple subcomponents that import each other's interfaces.

The Component Model is the foundation of WASI Preview 2 and is the basis for emerging tooling such as Fermyon Spin and wasmCloud. Bindings generators exist for Rust (wit-bindgen), TinyGo, JavaScript (jco), Python, C, and several other languages, and component runtimes are available in Wasmtime, WasmEdge, and others.

## What is WebAssembly used for in AI?

WebAssembly has become a foundational technology for client-side and edge artificial intelligence. Modern browsers and JavaScript runtimes expose Wasm as the high-performance compute path for machine learning libraries, and the Component Model and WASI extensions are increasingly used to package inference engines for server and edge deployment. Running models in the browser via Wasm keeps data on the user's device, which reduces latency and supports privacy-sensitive [on-device AI](/wiki/on_device_ai) workloads.

### In-browser inference

| Project | Wasm role | Notes |
|---|---|---|
| Transformers.js (Hugging Face) | Loads quantized ONNX models and runs them through ONNX Runtime Web's Wasm and WebGPU backends. | Provides a JavaScript API similar to the Python transformers library; supports dozens of model architectures. |
| ONNX Runtime Web | Compiles ONNX Runtime to Wasm with optional SIMD and threads; offers a WebGPU backend for accelerated tensor ops. | Default execution provider for Transformers.js and many [Hugging Face](/wiki/hugging_face) demos. |
| TensorFlow.js Wasm backend | Replaces the JavaScript CPU backend with a Wasm build of TensorFlow Lite kernels. | Often paired with the WebGL or WebGPU backend depending on hardware. |
| WebLLM | Compiles model graphs through MLC-LLM and TVM into WebGPU shaders, with a Wasm runtime for graph orchestration and quantization kernels. | In-browser chat with Llama, Mistral, Gemma, Phi, and other [large language model](/wiki/large_language_model) families; falls back to Wasm where WebGPU is unavailable. |
| [MLC LLM](/wiki/mlc_llm) | Same compiler stack as WebLLM, also targets native, iOS, and Android. | Demonstrates end-to-end LLM compilation across browser and device. |
| Web Stable Diffusion | Uses MLC-LLM tooling to compile the Stable Diffusion pipeline to WebGPU plus Wasm. | Runs the full image generation pipeline in the browser. |
| llama.cpp | Provides experimental Wasm builds and WASI ports of its inference loop. | Used in browser demos and in WASI hosts that want a single-binary LLM runtime. |
| Pyodide | Ships CPython, NumPy, SciPy, scikit-learn, and PyTorch (CPU) compiled to Wasm. | Used by JupyterLite and by Cloudflare Python Workers; lets data scientists run notebooks without a server. |

These tools share a similar architecture: model weights are downloaded and quantized, tensor kernels run on the GPU through WebGPU when available, and a Wasm module handles control flow, tokenization, sampling, and any kernels not yet ported to GPU shaders. Wasm SIMD and threads are particularly important for CPU inference, and Wasm 2.0 features such as relaxed SIMD give engines more freedom to map operations to native vector instructions.

WebLLM, described by its authors as "an open-source JavaScript framework that enables high-performance LLM inference entirely within web browsers," illustrates the division of labor: it leverages WebGPU for local GPU acceleration and WebAssembly for performant CPU computation, and in the authors' benchmarks against the native MLC-LLM stack it retains up to 80% of native decode speed. [10]

### Edge and serverless inference

On the server, WebAssembly runtimes such as Wasmtime, WasmEdge, and Wasmer have become a common substrate for AI workloads that need fast cold starts, strong isolation, and language portability. Cloudflare Workers AI exposes Meta Llama, Mistral, and other open-weight models behind a Workers API; user code that orchestrates these models runs as JavaScript or Wasm inside V8 isolates. [13] Vercel's AI runtime and Edge Functions similarly use V8 isolates that can host Wasm. Fermyon Spin offers a templated way to build Wasm-based microservices that call into local or remote inference. WasmEdge ships extensions for Llama-family models via [llama.cpp](/wiki/llama_cpp) and for ONNX Runtime, allowing inference inside a WASI sandbox without depending on a Python runtime.

The combination of Wasm portability, capability-based security, and microsecond-scale instantiation makes the format particularly well suited to running untrusted AI agent code, plug-in marketplaces for hosted assistants, and per-request inference glue at the edge. This positions Wasm as a portable runtime layer for [edge AI](/wiki/edge_ai) alongside GPU-accelerated paths such as [WebGPU](/wiki/webgpu).

## Is WebAssembly supported in all browsers?

WebAssembly is supported in 100% of major browsers in current use, including Chrome, Firefox, Safari, and Edge, and is available in Node.js, Deno, and Bun out of the box. As of 2025, caniuse data put global support at roughly 96% of tracked browser sessions, with coverage from Chrome 57+, Firefox 52+, Safari 11+, Edge 16+, Opera 44+, and Samsung Internet 7.2+. [21] The format is used in production by a long list of consumer and enterprise applications:

| Application | Use of Wasm |
|---|---|
| Figma | The core editor's vector engine is C++ compiled to Wasm. |
| Adobe Photoshop on the web | Large parts of the C++ Photoshop codebase are compiled to Wasm via Emscripten. |
| AutoCAD Web | The AutoCAD engine is shipped to the browser as Wasm. |
| Google Earth on the web | Earth's C++ rendering engine runs in the browser via Wasm. |
| 1Password | The cryptographic core of the 1Password browser extension and web client is Wasm. |
| eBay barcode scanner | Native barcode scanning library compiled to Wasm. |
| Amazon Prime Video | Performance-critical playback components delivered as Wasm. |
| Google Meet | Background blur and noise suppression use Wasm-based ML kernels. |
| Zoom Web | Wasm modules for video processing and audio. |
| Disney+ | Wasm components in their web player. |

Server-side adoption follows a similar pattern. Cloudflare has reported that its Workers platform processes trillions of requests per month, with a growing share running Wasm guests; Fastly Compute reports tens of microseconds of cold-start time for Wasm modules, an order of magnitude better than container-based serverless platforms; Shopify Functions allows merchants to upload Wasm modules to customize commerce logic; and the WebAssembly System Interface has become a portable target for plug-in systems in databases, observability tools, and developer platforms. [17]

## Criticism and limitations

WebAssembly's design choices come with trade-offs. Common criticisms and limitations include:

- **No direct DOM or browser API access.** A Wasm module must call into JavaScript to manipulate the DOM, dispatch events, or use most Web APIs. Bindings layers such as wasm-bindgen reduce the boilerplate but cannot eliminate the call overhead.
- **Bundle size.** Languages with large standard libraries or runtimes (Go's mainline compiler, the .NET runtime, CPython) produce multi-megabyte .wasm files; toolchain-specific solutions such as TinyGo, dead-code elimination, and Brotli compression mitigate but do not eliminate this.
- **Debugging.** Although DWARF debug info, source maps, and engine integrations have improved, debugging a Wasm program remains less ergonomic than debugging native or JavaScript code, especially across the JS-to-Wasm boundary.
- **Garbage collection.** Wasm GC reached cross-engine support only in 2023, which delayed efficient targets for managed languages such as Java, C#, Kotlin, and OCaml. Earlier ports had to ship their own runtime and garbage collector inside linear memory, inflating both binary size and memory use.
- **Cold start in some hosts.** Although standalone runtimes such as Wasmtime and Lucet measure cold start in microseconds, hosts that perform extensive validation, AOT compilation, or capability brokering on first instantiation can see latencies that are noticeable for very small workloads.
- **Threading model.** Wasm threads rely on SharedArrayBuffer in the browser, which requires servers to send specific cross-origin isolation headers. This complicates deployment for sites that depend on third-party content.
- **Component Model maturity.** As of 2026, the Component Model and WASI Preview 2 are widely implemented but still evolving, and tooling outside Rust and JavaScript is uneven.

## See also

- [JavaScript](/wiki/javascript)
- [Web Browser](/wiki/web_browser)
- [WebGPU](/wiki/webgpu)
- [Edge AI](/wiki/edge_ai)
- [On-device AI](/wiki/on_device_ai)
- [Node.js](/wiki/nodejs)
- [Rust](/wiki/rust)
- [Bytecode Alliance](/wiki/bytecode_alliance)
- [WASI](/wiki/wasi)
- [Wasmtime](/wiki/wasmtime)
- [Wasmer](/wiki/wasmer)
- [Transformers.js](/wiki/transformers_js)
- [WebLLM](/wiki/webllm)
- [ONNX](/wiki/onnx)

## References

1. World Wide Web Consortium. "World Wide Web Consortium (W3C) brings a new language to the Web as WebAssembly becomes a W3C Recommendation." Press release, December 5, 2019. https://www.w3.org/2019/12/pressrelease-wasm-rec.html.en
2. WebAssembly Working Group. "WebAssembly Core Specification" (1.0 Recommendation). W3C, December 5, 2019. https://www.w3.org/TR/wasm-core-1/
3. WebAssembly Working Group. "WebAssembly Core Specification" (2.0). W3C, 2024-2025. https://www.w3.org/TR/wasm-core-2/
4. Brendan Eich. "From ASM.JS to WebAssembly." brendaneich.com, June 17, 2015. https://brendaneich.com/2015/06/from-asm-js-to-webassembly/
5. Lin Clark. "Where is WebAssembly now and what's next?" Mozilla Hacks, February 28, 2017. https://hacks.mozilla.org/2017/02/where-is-webassembly-now-and-whats-next/
6. Mozilla, Fastly, Intel, Red Hat. "Announcing the Bytecode Alliance." Mozilla Hacks, November 12, 2019. https://hacks.mozilla.org/2019/11/announcing-the-bytecode-alliance/
7. WebAssembly project. "Wasm 2.0 Completed." webassembly.org news, March 20, 2025. https://webassembly.org/news/2025-03-20-wasm-2.0/
8. WebAssembly project. "Wasm 3.0 Completed." webassembly.org news, September 17, 2025. https://webassembly.org/news/2025-09-17-wasm-3.0/
9. Bytecode Alliance. "10 Years of Wasm: A Retrospective." 2025. https://bytecodealliance.org/articles/ten-years-of-webassembly-a-retrospective
10. Charlie Ruan, Yucheng Qin, Xun Zhou, Ruihang Lai, Hongyi Jin, Yixin Dong, Bohan Hou, Meng-Shiun Yu, Yiyan Zhai, Sudeep Agarwal, Hangrui Cao, Siyuan Feng, Tianqi Chen. "WebLLM: A High-Performance In-Browser LLM Inference Engine." arXiv:2412.15803, December 2024. https://arxiv.org/abs/2412.15803
11. mlc-ai. "web-llm: High-Performance In-Browser LLM Inference Engine." GitHub repository. https://github.com/mlc-ai/web-llm
12. Mozilla. "Pyodide: Bringing the scientific Python stack to the browser." Mozilla Hacks, April 16, 2019. https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-python-stack-to-the-browser/
13. Cloudflare. "WebAssembly (Wasm) - Cloudflare Workers documentation." https://developers.cloudflare.com/workers/runtime-apis/webassembly/
14. Cloudflare. "Bringing Python to Workers using Pyodide and WebAssembly." Cloudflare Blog, April 2, 2024. https://blog.cloudflare.com/python-workers/
15. Fastly. "How Lucet and Wasmtime make a stronger compiler, together." Fastly Blog, March 2, 2020. https://www.fastly.com/blog/how-lucet-wasmtime-make-stronger-compiler-together
16. WebAssembly project. "WebAssembly Specifications." https://webassembly.github.io/spec/
17. HTTP Archive. "WebAssembly" chapter, Web Almanac 2025. https://almanac.httparchive.org/en/2025/webassembly
18. Hugging Face. "Transformers.js documentation." https://huggingface.co/docs/transformers.js
19. Bytecode Alliance. "Wasmtime: A standalone runtime for WebAssembly." https://wasmtime.dev/
20. WASI subgroup. "WebAssembly System Interface." https://wasi.dev/
21. caniuse.com. "WebAssembly." Browser support tables, accessed 2025. https://caniuse.com/wasm