WebAssembly

component-model

WebAssembly2022–2026

WebAssembly / component-model

component-model

Repository for design and specification of the Component Model

Web Development Learning & Reference

Explore on GitHub Read Hacker News discussions

30Distinct people

43Mentions

0Explicit recommenders

1.4KGitHub stars

REPOSITORY AT A GLANCE

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, 8:59:20 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

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	13	13
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	9	9
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	8	8
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	8	8
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	5	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 GitHub

What Hacker News says

8 sources

peutetre·Dec 27, 2024

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

In Lua is so underrated

peutetre·Nov 21, 2024

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?

no_circuit·Nov 13, 2024

For the audience that would be looking to use the WASM Component Model, and not be an infrastructure implementer of it, whether or not they meet some definition of a method, the component model does define things called resources [1] that have "methods". You'll hold a "handle" to it like you would in your own programming language with the expected drop and/or GC semantics (once implemented [2]) because code is generated to access it like any other FFI like C/C++. With that in mind, the other confusing thing one may come across is composition vs linking within your WASM runtime that supports the Component Model. When you hear "composition" think of compile-time merging of libraries such that the bundle may have less unresolved dependencies of WASM code/implemented component interfaces. Anything unresolved needs to be linked at runtime with

Read the rest

your WASM runtime of choice, like wasmtime [3]. Pretty interesting reading/potential after reading if you ask me -- sounds like you could implement something like a custom Java classloader hierarchy [4]. But I'd agree with a statement saying it is still a long way for general usage. [1] https://github.com/WebAssembly/component-model/blob/5a34794d... [2] https://github.com/WebAssembly/gc [3] https://github.com/bytecodealliance/wasmtime/blob/ba8131c6bf... [4] https://www.digitalocean.com/community/tutorials/java-classl...

In Spin 3.0 – open-source tooling for building and running WASM apps

codelikeawolf·Apr 13, 2024

I don't think that's a very good goal. Jettisoning the DOM means jettisoning accessibility and being able to leverage everything that the browser gives you out-of-the-box. You have to render to a canvas and build everything from scratch. I think Wasm is great for supplementing a JS app, not replacing it (e.g. using a Wasm module to do some calculations in a Worker). I like to use the right tool for the job, and trying to use something other than JS to build a web app just seems a little janky to me. At one point, there was a Host Bindings proposal that would enable you to do DOM manipulation (it looks like it was archived and moved to the Component Model spec [1]). That would probably be the ideal way to avoid as much JS as possible. However, browser vendors have been heavily optimizing their JS runtimes, and in some cases, Wasm may actua

Read the rest

lly be slower than JS. I've been following Wasm's progress for several years, which has been slow, but steady. Ironically, I think the web is actually the worst place to use it. There's so much cool non-web stuff being done with it and I'm more interested to see where that goes. [1] https://github.com/WebAssembly/component-model?tab=readme-ov...

In Tree-shaking, the horticulturally misguided algorithm (2023)

hardwaresofton·Apr 3, 2024

Well the great thing about WebAssembly is that you can port QT or anything else to be at a layer below -- thanks to WebAssembly Interface Types[0] and the Component Model specification that works underneath that. To over-simplify, the Component Model manages language interop, and WIT constrains the boundaries with interfaces. IMO the problem here is defining a 90% solution for most window, tab, button, etc management, then building embeddings in QT, Flutter/Skia, and other lower level engines. Getting a good cross-platform way of doing data passing, triggering re-renders, serializing window state is probably the meat of the interesting work. On top of that, you really need great UX. This is normally where projects fall short -- why should I use this solution instead of something like Tauri[2] which is excellent or Electron? [0]: https://g

Read the rest

ithub.com/WebAssembly/component-model/blob/main/des... [1]: https://github.com/WebAssembly/component-model/blob/main/des... [2]: https://tauri.app/

In 3D + 2D: Testing out my cross-platform WASM graphics engine

mnemonik·Jan 26, 2024

Yes, you can use the component model (and other tooling like WIT) without using WASI. Yes, the component model is a standard developed under the umbrella of the W3C's WebAssembly Community Group. That said, while it is relatively stable and hasn't changed much in the last year or so, the component model has not graduated through all the phases of the standardization process yet. It doesn't, for example, have a formal specification yet, although its canonical ABI does have a reference implementation in Python. https://github.com/WebAssembly/component-model/

In WASI 0.2.0 and Why It Matters

boomskats·Jan 26, 2024

I thought this keynote presentation[0] by Luke Wagner at Wasmcon was great and covered it very well. I also found the WIT Format design doc[1] in the component model repo to be the most complete explanation of how it's all going to hang together. [0]: https://www.youtube.com/watch?v=tAACYA1Mwv4 [1]: https://github.com/WebAssembly/component-model/blob/main/des...

In WASI 0.2.0 and Why It Matters

jauntywundrkind·Jan 9, 2024

While I don't necessarily agree with the unnecessary, unsupported, casual, & cheap (provided with zero substantiating/contestable support) contempt culture here ("unshackle the web from the mess that is JavaScript", "places that don't really need these problems to be solved")... WebAssembly component-model is being developed to allow referring to and passing complex objects between different modules and the outside world, by establishing WebAssembly Interface Types (WIT). It's basically a ABI layer for wasm. This is a pre-requisite for host-object bridging, bringing in things like DOM elements. Long running effort, but it's hard work and there's just not that many hands available for this deep work. Some assorted links with more: https://github.com/WebAssembly/component-model https://www.fermyon.com/blog/webassembly-component-model https:

Read the rest

//thenewstack.io/can-webassembly-get-its-act-together-... A preview-2 should be arriving sometime somewhat soon. It's just hard work. It's happening. And I think the advantages Andy talks to here illuminate very real reasons why this tech can be useful broadly. The ability to have plugins to a system that can be safely sandboxed is a huge win. That it's in any language allows much wider ecosystem of interests to participate, versus everyone interested in extending your work also having to be a java or c++ or rust developer.

In Missing the Point of WebAssembly