This is typically called an IDL and TLA mentions inspiration from several examples under "prior art." At the top is the Web Assembly Interface proposal which has the wit [0] format,
[0] https://github.com/WebAssembly/component-model/blob/main/des...
In Experimental Rust Feature: Safer Interoperable ABIWebAssembly
component-model
WebAssembly2022–2026
WebAssembly / component-model
component-model
Repository for design and specification of the Component Model
30Distinct people
43Mentions
0Explicit recommenders
1.4KGitHub stars
What to know before exploring
What it is
Repository for design and specification of the Component Model
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- webassembly/wasi · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 11:00:58 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year43 dated mentions
Observed mentions: 2022-04-01 08:38:02 UTC to 2026-06-12 15:58:04 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 13 | 0 | 13 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 9 | 0 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 8 | 0 | 8 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 0 | 5 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Component Model design and specification
This repository is where the Component Model is being standardized. For a more
user-focused explanation, take a look at the Component Model Documentation.
This repository contains:
high-level goals, use cases, design choices and FAQ docs
low-level WIT, text format, binary format, linking, concurrency and
ABI docs
a growing WAST test suite
In the future, this repository will additionally contain a formal spec and a
reference interpreter.
Milestones
The Component Model is currently being developed incrementally as part of WASI
"Developer Preview" releases. The Component Model features enabled as part of a
WASI Developer Preview release are kept stable by producer and consumer tools so
that they can be used outside the browser in production settings to collect
real-world feedback.
The current WASI Developer Preview releases are:
0.2.0: the first release based on the Component Model; includes
shared-nothing and shared-everything linking, a variety of high-level
value types, resource types with handles, and WIT.
0.3.0: the first release with native concurrency support in the Component
Model and WIT; adds async functions, streams and futures as
well as new ABI built-in functions (additions are marked by the 🔀
emoji throughout the repo).
0.3.1: adds the map<K,V> type (🗺️) and the implements and external-id
annotations (🏷️).
Subsequent WASI Developer Preview releases will include other emoji-gated
features such as cooperative threads (🧵).
Contributing
All Component Model work is done as part of the W3C WebAssembly Community Group.
To contribute to any of these repositories, see the Community Group's
Contributing Guidelines.
Read the full README on GitHubWhat Hacker News says
13 sourcesThey were standardizing a subset of POSIX, until they found out why POSIX is mostly legacy nowadays.
So, now the effort is being rebooted with WASM Components.
https://github.com/WebAssembly/component-model
In Goodbye to the C++ Implementation of Zig> WASM is a runtime only. It does not try to define a component model.
This GitHub page seems to contradict that:
https://github.com/WebAssembly/component-model/blob/main/des...
In Wasmer takes WebAssembly libraries mainstream with WAIThat's exactly what the component model defines, but it looks to be more useful than COM or CORBA.
https://github.com/WebAssembly/component-model/blob/main/des...
In Wasmer takes WebAssembly libraries mainstream with WAICheck out the component model proposal, which adds a stable ABI for rich types like strings, arrays, structs, etc.
https://github.com/WebAssembly/component-model
In Show HN: A tiny WASM compiler and runtime for demonstration purposes> or a better arbitrary runtime like WASM
> It's the component and security model itself.
WASI and the WASM component model proposal [1] are moving to a capability based system (enabled by unforgeable references aka `reftype`) and to isolation between different parts of your code, which would make isolating and restricting dependencies really easy.
Combined with interface types (essentially a universal cross-language ABI) the ecosystem has the building blocks for building very secure systems.
Sadly progress has been very slow, with no end in sight, but I remain hopeful.
[1] https://github.com/WebAssembly/component-model
In The best thing we can do today to JavaScript is to retire itThe component model [1] with interface types will enable nicer tooling for things like linking and combining different languages, but it's been very slow moving and is still in flux.
[1] https://github.com/WebAssembly/component-model
In From a WebAssembly PerspectiveRead this bit again, it feels very bizarre to me and is like they're misunderstanding how server side development and containers work...?
> The whole isolation model that keeps WebAssembly from being able to attack the hosts through the browser was the same kind of [security] model we wanted on the cloud side,” Butcher explained.
I then went to the fermyon.com website, and their first line says
> WebAssembly-powered cloud tools
And later in the page leads to the WASM 'component model' at https://github.com/WebAssembly/component-model/blob/main/des... which actually mentions that!
> Embeddability: design components to be embedded in a diverse set of host execution environments, including browsers, servers, intermediaries, small devices and data-intensive systems.
So now I'm extra confused. WASM lets you run compiled languages like C# in t
Read the rest
he browser. You can already run that on the server side. You can run it in a container. What problem is WASM solving here? Unfortunately the language is hard to follow so even if they have answered it, it's not very accessible.
No comment on the other points (I also prefer Wasmtime), but:
I believe the linking proposal is dead for now and replaced by the component model: https://github.com/WebAssembly/component-model
The wasmtime implementation is in progress.
In Wasmer – Universal WebAssembly RuntimeWhat is the common spec for Knative? It seems like one runs an app as normal in a container and then the special scaling sauce is handled by Knative.
When I think of a portable spec for serverless, I think of something more like a Trait of an Interface that needs to be implemented, less a app hosting model. If you think about it like that, then Web Assembly component model [1] would be a great fit for defining an interface that could be implemented in a variety of languages.
[1]: https://github.com/WebAssembly/component-model/blob/main/des...
In Netlify Edge Functions: A new serverless runtime powered by DenoAre subprojects intended to eventually make it into the main spec or do they remain standalone? GC, threads, atomics, component-model, interface-types... Im not sure what to expect to eventually make it into this spec & what will continue developmemt semi-independently.
Personally https://github.com/WebAssembly/component-model/pull/23 feels like it marks the start of webassembly's first full era. We need interoperation, webassembly needs to really be embeddable, & only then can we really understand & explore what webassembly means to the world.
(Rust got an early start with wasm-bindgen, doing all the lifting on their side, but it's not reasonable & only semi-interoperable having each language rebuild that bindgen system & abingor itself... hence canonical abi & component-model.)
Edit: tux3 has a good comment linking the changelog, noting
Read the rest
that indeed numberous specs have been integrated. https://news.ycombinator.com/item?id=31087610
Really excited for multiple table per module support! The idea of a capabilities based sort of system, where a module is handed a couple working sets of data as SharedArrayBuffers to work g communicate with, is quite compelling.
The Interface Types and Module Linking proposals were recently superseded by the Component Model proposal, which unifies the two: https://github.com/WebAssembly/component-model
In Spin – WebAssembly Framework