There is an issue open for instantiating modules at runtime: https://github.com/WebAssembly/component-model/issues/423
In WASI 0.3WebAssembly
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, 12:54:37 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
43 sourcesIf you’re poking around WASM consider falling down the Component Model rabbit hole:
https://github.com/WebAssembly/component-model/blob/main/des...
Threading is actively being worked on right now (to be released in 0.3.x, soon), and some changes just made their way into LLVM as well:
https://github.com/llvm/llvm-project/pull/175800
In Theseus: Translating Win32 to WASMRelevant: https://github.com/WebAssembly/component-model/issues/525
In my experience people are often disappointed by the shared-nothing architecture of the component model. I guess that shared-nothing architecture makes it impossible to properly share GC objects across component boundaries. But they can still be shared across core module boundaries.
In Making WebAssembly a first-class language on the WebAt a high level this sounds great. But looking into the details about how the component model will be implemented, it looks very complicated due to concurrency:
https://github.com/WebAssembly/component-model/blob/main/des...
In Making WebAssembly a first-class language on the WebIt's proposed here: https://github.com/WebAssembly/component-model/issues/598
Basically, it's sugar for `package` and `world` in the case where you aren't actually defining a world for others to use, and just for your own use. In such a case, the package and world names are irrelevant anyway.
In Making WebAssembly a first-class language on the WebDisclaimer: I work on Jco, one of the user-facing Bytecode Alliance WASM JS ecosystem projects
Just a note, but there is burgeoning support for this in "modern" WebAssembly:
https://github.com/bytecodealliance/jco/tree/main/examples/c...
If raw WebIDL binding generation support isn't interesting enough:
https://github.com/bytecodealliance/jco/blob/main/packages/j...
https://github.com/bytecodealliance/jco/blob/main/packages/j...
https://github.com/bytecodealliance/jco/blob/main/packages/j...
Support is far from perfect, but we're moving towards a much more extensible and generic way to support interacting with the DOM from WebAssembly -- and we're doing it via the Component Model and WebAssembly Interface Types (WIT) (the "modern" in "modern" WebAssembly).
What's stopping us the most from being very effective in browsers is the still-expe
Read the rest
rimental browser shim for components in Jco specifically. This honestly shouldn't be blocking us at this point but... It's just that no one has gotten around to improving and refactoring the bindings.
That said, the support for DOM stuff is ready now (you could use those WIT interfaces and build DOM manipulating programs in Rust or TinyGo or C/C++, for example).
P.S. If you're confused about what a "component" is or what "modern" WebAssembly means, start here:
https://component-model.bytecodealliance.org/design/why-comp...
If you want to dive deeper:
https://github.com/WebAssembly/component-model
The structured concurrency paradigm in workflows is stricter to what I'm reading here [1]. The whole execution model is different from the Task [2], as workflows are transparently unloaded and replayed.
Obelisk has a concept called join sets [3], where child executions are submitted and awaited. In the future I plan on adding cancellation and allow custom cleanup functions.
[1] https://github.com/WebAssembly/component-model/blob/main/des...
[2] https://github.com/WebAssembly/component-model/blob/main/des...
[3] https://obeli.sk/docs/latest/concepts/workflows/join-sets/
In Show HN: Obelisk – a WASM-based deterministic workflow engineFunnily enough, that's what [wRPC](https://github.com/bytecodealliance/wrpc) is designed to do, using the small and efficient [Component Model Value Encoding](https://github.com/WebAssembly/component-model/blob/main/des...), largely based on [Core Wasm spec](https://webassembly.github.io/spec/core/).
For example, here's an example of a Web App using [`wasi:keyvalue` interface](https://github.com/WebAssembly/wasi-keyvalue/) via WebTransport using wRPC: https://github.com/bytecodealliance/wrpc/tree/8e9de3b446ac05...
In Extensible WASM Applications with GoTo further explain: the standard WASM ABI is essentially just a C ABI, so you can pass integers and pointers around, but you can't do much more; anything more complex needs to be built on top of that, which precludes binding to the DOM API directly.
The existing workarounds for this glue the JS DOM API to the guest language through glue on both sides, but this means that you have to pay the penalty of marshalling through JS for every single call you make.
There's a solution in the works to make direct interaction possible, but it's proven to be quite challenging to finalise: essentially, you need a high-level ABI that can provide a safe and fast interface between the host and whatever guest language, and defining that in a way that makes everyone happy is non-trivial.
For more information, see the Component Model [0] and WIT [1]; the idea
Read the rest
is that you will eventually be able to compile your WASM to WASM Components, which can then interface with the host (or other WASM components) through the WIT IDL, including interacting with the browser's DOM.
[0]: https://github.com/WebAssembly/component-model
[1]: https://github.com/WebAssembly/component-model/blob/main/des...
I've been developing on top of wasm (wasmtime, specifically) for several years now.
I personally have my doubts about how broadly the components specification (which this cloud platform seems to depend on) will be adopted. Maybe I'm just not very smart, but it feels like one of the things I loved the most about WebAssembly, its simplicity, is being lost.
To get even basic things done with WASI, you now have to figure out which flavor to pull in (preview 1, preview 2, ... need any async [0], that's coming preview 3?), learn a new IDL language [1] that defines the component's spec, figure out its codegen toolchain [2]. It's all very reminiscent of COM, CORBA and all the other times this has been tried in the past.
In any case, wasmtime is an amazing project and I'm grateful for it. They've already had to bifurcate the library to support WAS
Read the rest
I and components. I just hope non-WASI/component code retains its status as a first class citizen in the project.
[0] https://docs.google.com/presentation/d/1MNVOZ8hdofO3tI0szg_i...
[1] https://github.com/WebAssembly/component-model/blob/main/des...
[2] https://github.com/bytecodealliance/wit-bindgen
I am kind of worried that the eagerness for more WASM features may irremediably harm the young ecosystem. Most of what Go added to WASM could be done natively if the component model proposal [1] was merged already.
The standard evolves slowly and as adoption rises we risk having to support more and more non-standard features forever, like WASI and now this.
[1] https://github.com/WebAssembly/component-model
In Extensible WASM Applications with GoFully agree with your point here, but wanted to point out that including C dependencies is actually one of the biggest reasons why Python support is hard for WebAssembly too.
Bolstering your point -- smart-and-hardworking people are working on this, which results in:
https://github.com/bytecodealliance/componentize-py/
which inspired
https://github.com/WebAssembly/component-model/blob/main/des...
with some hard work done to make things work:
https://github.com/dicej/wasi-wheels
It's a fun ecosystem -- the challenge is huge but the work being done is really fundamentally clean/high quality, and the solutions are novel and useful/powerful.
In WASM will replace containers> Correct me if I’m wrong, but that’s only possible if you separate runtime threads from OS threads, which sounds straightforward but introduces problems relating to stack-lifetimes in continuations so it introduces demands on the compiler and/or significant runtime memory overhead - which kinda defeats the point of trying to avoid blocking OS threads in the first place.
Correct -- note that the async implementation does not address parallelism (i.e. threading) -- it's a language +/- runtime level distinction.
The overhead is already in the languages that choose to support -- tokio in rust, asyncio in python, etc etc. For those that don't want to opt in, they can keep to synchronous functions + threads (once WASI threads are reimagined, working and stable!)
You can actually solve this problem with both multiple stacks and a continuation b
Read the rest
ased approach, with different tradeoffs.
> I’m not belittling the achievement there - I’m just saying (again, correct me if I’m wrong) there’s a use-case for function-colouring in high-thread, high-memory applications.
>
> …but if WASI is simply adding more options without taking anything away then my point above is moot :)
Didn't take it as such! The ability to avoid function coloring does not block the implementations of high-threads/high-memory applications, once an approach to threading is fully reconsidered. And adding more options while keeping existing workflows in place is definitely the goal (and probably the only reasonable path to non-trivial adoption...).
How to do it is quite involved, but there are really smart people thinking very hard about it and trying to find a cross-language optimal approach. For example, see the explainer for Async:
https://github.com/WebAssembly/component-model/blob/main/des...
There are many corners (and much follow up discussion), but it's shaping up to be a pretty good interface, and widely implementable for many languages (Rust and JS efforts are underway, more will come with time and effort!).
The WebAssembly component model is aimed at having composable components that can call each other. The components can be written in any language, compiled to WebAssembly, and interoperate: https://github.com/WebAssembly/component-model/
Extism is a plugin framework for WebAssembly:
https://extism.org/
https://github.com/extism/extism
Postgres and Extism: https://dylibso.com/blog/pg-extism/
Wasm plugins for Zellij: https://zellij.dev/documentation/plugins
Visual Studio Code can run WebAssembly extensions: https://code.visualstudio.com/blogs/2024/05/08/wasm
A project to bring WebAssembly plugins to Godot: https://github.com/ashtonmeuser/godot-wasm
WasmEdge can be embedded in applications: https://wasmedge.org/docs/embed/overview
Wasmer can be embedded in applications: https://blog.wasmer.io/executing-webassembly-in-your-rust-ap...
Wasmtime
Read the rest
can be embedded in applications: https://docs.wasmtime.dev/lang.html
Eventually by using the component model which will expose the DOM API. It will get to direct wasm to WebIDL calls one day:
https://github.com/WebAssembly/component-model
The component model is being used for the WebAssembly System Interface (WASI). WASI provides operating system integration for wasm applications outside the browser:
https://github.com/WebAssembly/WASI/tree/main
In the meantime you can use JavaScript glue code auto-generated by your toolchain to access the DOM. This will be made better with builtins like the js-string-builtins proposal:
https://github.com/WebAssembly/js-string-builtins/blob/main/...
You can call JavaScript functions and DOM methods from wasm like this example from Hoot, which is a Scheme to wasm compiler:
https://spritely.institute/news/building-interactive-web-pag...
In Ask HN: What are some unpopular opinions you got?Showing the 15 most recent of 43 sources. Enable JavaScript to search and browse every indexed mention.