Draft:Interface definition language for WebAssembly components
WIT is the IDL language used for WASI in WebAssembly… existing WebAssembly article was already long
From Wikipedia, the free encyclopedia
WIT (WebAssembly Interface Type, sometimes expanded as Wasm Interface Type, file extension: .wit) is an interface description language (IDL) used to define the interfaces of WebAssembly components.[1] Developed under the W3C WebAssembly Community Group as part of the Component Model proposal, WIT provides a language-agnostic way for WebAssembly modules written in different programming languages to describe the functions and data types they import and export, enabling cross-language interoperability without requiring a shared runtime or foreign function interface.[2]
 | Review waiting, please be patient.
This may take 8 weeks or more, since drafts are reviewed in no specific order. There are 3,102 pending submissions waiting for review.
Where to get help
How to improve a draft
You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Editor resources
Reviewer tools
|
WIT is the standard IDL for WebAssembly System Interface (WASI) since the release of WASI 0.2 in January 2024,[3] and is used by runtimes and platforms including Wasmtime, Fastly Compute, Fermyon Spin, and wasmCloud.[4]
History
The concept of interface types for WebAssembly was first publicly proposed in August 2019 by Lin Clark of Mozilla, who described a mechanism to let WebAssembly modules exchange high-level values such as strings and records without manual memory-management glue code.[5] The early work resulted in a formal WebAssembly "interface-types" proposal housed in the W3C WebAssembly Community Group.[6]
An earlier IDL called WITX, based on the WebAssembly text format, was used to define the APIs of WASI Preview 1 (also known as WASIp1).[7] As work on the broader Component Model advanced — championed by Luke Wagner, a Distinguished Engineer at Fastly and co-chair of the W3C WebAssembly Working Group — the interface-types proposal evolved into the WIT format that is in use today.[8] WIT replaced WITX with a richer type system, support for modular interface packages, and the ability to describe both imports and exports of a component in a single definition.[9]
On 25 January 2024, the WASI Subgroup of the W3C WebAssembly Community Group voted to release WASI 0.2 (WASIp2), which formally adopted the Component Model and made WIT the standard way to define all WASI interfaces going forward.[3]
Design
Core concepts
A WIT definition is organized around two main constructs: interfaces and worlds.[1]
An interface is a named collection of type definitions and function signatures that describes a focused piece of functionality—for example, reading from a file system or making an HTTP request. Interfaces are grouped into packages, which carry a two-level namespace (a namespace field identifying the organization or registry, and a package field naming the logical group).[10]
A world aggregates a set of imported and exported interfaces and types, expressing what features a component offers and what features it depends on. Worlds serve as the compilation target: a component author selects a world, and the component's binary must satisfy all of its imports and exports.[1]
Type system
WIT supports primitive types (booleans, integers of various widths, floating-point numbers, characters, and strings) as well as compound types including records, variants (tagged unions), enums, flags (bitfield sets), tuples, lists, options, and results.[11] The type system is designed so that every WIT type can be mechanically lowered to the Canonical ABI, the binary calling convention that components use at the boundary.[12]
Language-agnostic bindings
Because WIT definitions are independent of any source language, toolchains can generate idiomatic bindings automatically. For example, the wit-bindgen project produces Rust, C, C++, Go, and C# bindings from a .wit file, while Jco targets JavaScript and TypeScript.[13] This allows a component written in one language to be consumed by a host or another component written in a different language without hand-written FFI code.[14]
Adoption
WIT is integral to the server-side and edge-computing WebAssembly ecosystem. Fermyon's Spin framework uses WIT-defined interfaces to let developers write serverless functions in any supported language and deploy them on Fermyon Cloud or self-hosted infrastructure.[15] The Cloud Native Computing Foundation (CNCF) incubation-stage project wasmCloud relies on WIT to define the capability contracts between application components and infrastructure providers; American Express has used wasmCloud to build an internal function-as-a-service platform built on WebAssembly components.[16] Microsoft has adopted WIT for WebAssembly-based extension development in Visual Studio Code.[13]
Industry analysts at InfoWorld and The New Stack have characterized the Component Model (and by extension WIT) as a potential enabler of a "Docker moment" for WebAssembly, in which portable, composable components could complement or replace containers in cloud-native deployments.[17][18]