A. Sure, but it isn't sufficiently beneficial for the cost.
B. WebAssembly is immature for developing a plugin system because of the lack of a sufficient ABI: https://github.com/WebAssembly/component-model
C. There aren't any other languages that meet the criteria. Lua was a no-go from the start. The maintainers did not like the language, and it necessitated adding more C code to Helix which could complicate building even further. https://github.com/helix-editor/helix/discussions/3806#discu...
In Steel – An embeddable and extensible Scheme dialectWebAssembly
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, 10:22:47 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
9 sourcesThat's currently impossible. It requires the component model[1] to be figured out and that's taking a ridiculous amount of time because as anyone who has tried this before (and many have) this is really hard (languages have different semantics, different rules, different representations etc.).
If they do manage to get it working somehow, it will indeed be very exciting... but I've been waiting for this for several years :D (I was misled to believe this sort of modular thing was possible : but that's false unless you generate lots and lots of intermediate JS to glue different modules - and then all "communication" goes through JS, nothing goes directly from one module to another - which completely defies any possible performance advantage over just doing pure JS) so don't hold your breath.
[1] https://github.com/WebAssembly/component-model
In WASM by exampleAfaik, there's no means to pass in imported functions right now.
Rust has a very extensive bindgen to make it kind of look like you can, but it's really a huge payload of js running on the page's main-thread that's converting back and forth. At significant cost.
We just shipped garbage collection, which is one precondition to actually being able to pass things around (so things passed in can participate properly in gc). Next is component-model, which allows for passing non-trivial objects around; currently it's just primitives like numbers that can be passed. After that goes in, hopefully it won't be long before we have host-object bridging, where platform objects can be sent across. https://github.com/WebAssembly/component-model
In W3C Community Group Draft Report – WebGPU ExplainerAFAIK GC is (mostly) irrelevant for "direct DOM access", you would rather want to hop into the following rabbit hole:
- reference types: https://github.com/WebAssembly/reference-types/blob/master/p...
- interface types (inactive): https://github.com/WebAssembly/interface-types/blob/main/pro...
- component model: https://github.com/WebAssembly/component-model
If this looks like a hot mess, that's because it is. Compared to that, the current solution to go through a Javascript shim doesn't look too bad IMHO.
In Bringing garbage collected programming languages efficiently to WebAssemblyThe wasm idl (called WIT) is actively being worked on here: https://github.com/WebAssembly/component-model/blob/main/des...
Being able to access DOM is definitely an objective. It's just taking a lot longer than folks guessed to build a modular wasm ABI.
In Rust Is Surging Ahead in WebAssembly (For Now)The WASM Component Model
https://github.com/WebAssembly/component-model
In Reaching the Unix philosophy's logical extreme with WebAssembly> "Component model interfaces always support link-time interposition."
>
> Like WTF does this mean? The repo tells me nothing
Directly above the sentence you quoted:
"Interposition in the context of WASI interfaces is the ability for a Webassembly instance to implement a given WASI interface, and for a consumer WebAssembly instance to be able to use this implementation transparently. This can be used to adapt or attenuate the functionality of a WASI API without changing the code using it."
> and I've still yet to see a clear write-up about what WASI is.
In the same document: [0]
> WTF is wit?
The first link in that document ("Starting in Preview2, WASI APIs are defined using the Wit IDL.") is [1].
> I click on "legacy" and I see preview0 and preview1, which are basically unreadable proto-specs.
The README for the legacy directory [2] cle
Read the rest
arly explains what they are.
> Where's a single well-written WASI spec?
"Development of each API happens in its own repo, which you can access from the proposals list." [3]
> Whatever WASI is doing, I don't like it.
Clearly not - you've gone out of your way to ignore all of the documentation that answer your questions.
> And neither does AssemblyScript team apparently
The AssemblyScript team have a bone to pick with WASI based on their misunderstanding of what WASI is for (it is not intended for use on the web) and WASI's disinterest in supporting UTF-16 strings. You can see for yourself in [4].
[0]: https://github.com/WebAssembly/WASI/tree/main#wasi-high-leve...
[1]: https://github.com/WebAssembly/component-model/blob/main/des...
[2]: https://github.com/WebAssembly/WASI/blob/main/legacy/README....
[3]: https://github.com/WebAssembly/WASI/blob/main/Proposals.md
[4]: https://github.com/WebAssembly/WASI/issues/401
The Web Assembly Component Model (1) can't land soon enough.
(1) https://github.com/WebAssembly/component-model
In WebAssembly is eating the database?This depends chiefly on the component-model work shipping. https://github.com/WebAssembly/component-model
At the heart is an longstanding wasm "interface types" idea (WIT), defined by a IDL, https://github.com/WebAssembly/component-model/blob/main/des...
Once we know how bits of wasm talk to each other we can have browsers expose web platform "host objects" via this standard inter-module means.
While an interesting topic to most app developers, this is pretty off-topic for language nerds. It will greatly level implementations when it becomes available, as opposed to those willing to pour in enormous effort writing their own serializing bridges... but it doesnt really alter what the language can do and how it will work in wasm. This talk is, to me, more about languages. WIT & host objects will be an enormous boom but they overall won't mu
Read the rest
ch affect language design.