HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
bytecodealliance
wit-bindgen
Rust2022–2025
bytecodealliance / wit-bindgen

wit-bindgen

A language binding generator for WebAssembly interface types

Web DevelopmentLibraries & SDKs
Explore on GitHubRead Hacker News discussions
11Distinct people
13Mentions
0Explicit recommenders
1.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A language binding generator for WebAssembly interface types

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

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:56:56 AM 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 year13 dated mentions

Observed mentions: 2022-04-01 07:21:02 UTC to 2025-08-17 00:15:38 UTC.

0123452022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 5 mentions; 0 submissions, 5 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

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.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC505
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC404
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC211
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

What Hacker News says

13 sources
yoshuaw·Aug 17, 2025
We are more or less trying to solve this exact problem with Wasm Components [1]. If core WebAssembly is a portable instruction format, WebAssembly Components are a portable executable/linkable format. Using them is unfortunately not yet quite as easy as using repr(wasm)/extern "wasm". But with wit-bindgen [2] and the wasm32-wasip2 target [3], it's not that hard either. [1]: https://youtu.be/tAACYA1Mwv4 [2]: https://github.com/bytecodealliance/wit-bindgen [3]: https://doc.rust-lang.org/nightly/rustc/platform-support/was...
In Rust in 2025: Targeting foundational software
zackangelo·Feb 14, 2025
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
In WASM-Native Orchestration
n42·Nov 27, 2023
Wasmer is a VC company building a platform that depends on the existence of these platform APIs – sockets, threads, forking, etc. They have a vested interest in the existence of these APIs, and the health of the developer ecosystem, to stay alive. From here, it kind of seems like the fundamental foundation of everything Wasmer is building. Meanwhile, Bytecode Alliance is a registered non-profit with many large corporate backers. They are building out the WASI standard with careful due diligence to learn from and avoid the mistakes we have found in POSIX. BCA has their own financial incentives, and they are aligned differently than yours. BCA ultimately is moving slower than works for Wasmer. So I guess you were faced with three options: A) wait for BCA, and do nothing B) work with BCA and push it forward C) fork it and do it yourself. So
Read the rest
you chose to fork it and reimplement POSIX with all its warts. I assume because this applies pressure to the community (candidly, a good thing) while letting you make progress immediately. Where I, and I assume others, have issue with all of this is: You have chosen a name that has created confusion in an already confusing space. You have whitewashed it by promoting it as a new open standard, but the controlling entity realllyy is just Wasmer[0]. You have demonstrated through your actions a complete lack of willingness to work with people in the community, preferring to strong-arm with veiled threats[1] or perverting incentives financially[2]. The issue isn't with WASIX, but with you and your actions. I have no confidence in your ability to lead this community forward in a way that has my (our) interests ahead of your company's. [0]: https://github.com/wasix-org/wasix-governance-meeting-notes/blob/5135516d091d1bc38… [1]: https://github.com/bytecodealliance/wit-bindgen/issues/306 [2]: https://github.com/ziglang/zig/issues/17115
In $20k bounty was claimed
phickey·Nov 15, 2023
The component model is already shipping in Wasmtime, and will be stable for use in Node.js and in browsers via jco (https://github.com/bytecodealliance/jco) soon. WASI Preview 2 will be done in December or January, giving component model users a stable set of interfaces to use for scheduling, streams, and higher level functionality like stdio, filesystem, sockets, and http on an opt-in basis. You should look at wit-bindgen (https://github.com/bytecodealliance/wit-bindgen) to see some of the languages currently supported, and more that will be mature enough to use very soon (https://github.com/bytecodealliance/componentize-py) Right now jco will automatically generate the JS glue code which implements a Component Model runtime on top of the JS engine's existing WebAssembly implementation. So, yes, Components are a composition of Wasm Modul
Read the rest
es and JS code is handling passing values from one module/instance to another. You still get the performance benefits of running computation in Wasm. One day further down the standardization road, we would like to see Web engines ship a native implementation of the Component Model, which might be able to make certain optimizations that the JS implementation cannot. Until then you can consider jco a polyfill for a native implementation, and it still gives you the power to compose isolated programs written in many languages and run them in many different contexts, including the Web. (Disclosure: I am co-chair of WASI, Wasmtime maintainer, implemented many parts of WASI/CM)
In WASM by example
matei_radu·Nov 4, 2023
Thank you! To your point, the primary consideration for choosing the languages is their support for WebAssembly, and WASI in particular. Due to Spin's heavy use of WASI and the component model, languages that have first party support in the WIT bindings generator (https://github.com/bytecodealliance/wit-bindgen) are the easiest to implement, followed by languages that can be built on top of the support for those with first party support. For example, the JavaScript support is built by embedding QuickJS (in particular, Shopify's Javy project — https://github.com/fermyon/spin-js-sdk), which then uses the Rust SDK. (As a side note for the JS support — adapting QuickJS has been extremely helpful in getting JS support out; however, we are in the process of rebuilding the JS runtime using SpiderMonkey (with which a few people on the team have s
Read the rest
ignificant experience) and JCO (https://github.com/bytecodealliance/jco), and the web platform compatibility makes it a significantly better proposition for things like 3rd party dependencies). C# is an interesting one — the .NET team at Microsoft (and in particular Steve Sanderson from that team) has been making tremendous progress in ahead-of-time compilation for .NET and generating Wasm and WASI compatible binaries (as opposed to their initial approach on Blazor), and experimenting with that led us to build support for Spin as well. Finally, we do a lot to support other popular languages and their Wasm support — two examples: Python (https://github.com/bytecodealliance/componentize-py) and Java / TeaVM (https://github.com/fermyon/teavm-wasi), for which we haven't fully integrated Spin support, but we hope to get there soon. I hope this explains a bit our process on language support, happy to expand on any point here. Enjoy your weekend!
In Spin 2.0 – open-source tool for building and running WASM apps
phickey·Jan 31, 2023
Wasmtime's `wasmtime-py` embedding in python has support for Wasm Components: https://github.com/bytecodealliance/wasmtime-py#components (disclosure, I helped create it) The remaining piece of the puzzle would be to create a wit-bindgen guest generator https://github.com/bytecodealliance/wit-bindgen#guests for this build of the python interpreter. You could then seamlessly call back and forth between the host and guest pythons, without even knowing that wasmtime is under the hood.
In WebAssembly: Adding Python support to WASM language runtimes
syrusakbary·Sep 8, 2022
> But we have been noticing an unfortunate trend that some developers have chosen to work contrary to the component model, creating strong links to their own host runtimes. Going this route results in platform lock-in on one hand, and the pointless re-authoring of the same code (tooled for slightly different hosts) on the other. Oh dear lord. This is such a twisted narrative. The Component Model is a proposal that is only supported by one runtime out of the 20 used in production, none of them in the browser (don't look for it in v8, SpiderMonkey or Javascript Core, Wazero, Wasmer, Wizard Engine, WAVM, ...). So if there's anything that actually locks you in... is probably that! Even when Wasmer tried to add support for it on wit-bindgen (precursor for the Component Model), the same people from the Bytecode Alliance who are working on the C
Read the rest
omponent Model proposal rejected it [1]. Do they really want collaboration and not lock-in? One begins to wonder. It gets even more funny when you continue reading the article and you also realize that all people in the WasmDay committee that decides what get's in our out their CNCF conference are also part of the Bytecode Alliance. When the only competition they "cheer" is the one that comes from their approved friends. I would highly encourage everyone to read some of the practices of the Bytecode Alliance that the AssemblyScript community has redacted, it might be eye opening! [2] [1] https://github.com/bytecodealliance/wit-bindgen/issues/306 [2] https://www.assemblyscript.org/standards-objections.html
In The Risks of WebAssembly
matei_radu·Apr 1, 2022
Hi, and thanks for your comment! (one of the authors of Spin here.) First, both Spin and the component model are in their early stages, but there are a few things I'd mention here: - as you correctly pointed out, all "trigger" interfaces are based on WIT (https://github.com/bytecodealliance/wit-bindgen/blob/main/WI...), the new WebAssembly interface format, so a) building a WebAssembly binary that implements a trigger interface can be done pretty easily in languages with bindgen support, and b) extending Spin with a new trigger type can also be done by starting with the WIT interface (really early on this topic, but here's an example — https://spin.fermyon.dev/extending-and-embedding/) - we want to add support for defining component dependencies, and dynamically linking them at runtime based on the environment. - all "platform features" w
Read the rest
e want want to add to Spin will be initially based on host implementations for WebAssembly interfaces (you can see an early example of this in this PR — https://github.com/fermyon/spin/pull/165) - we are closely following the tooling in the component model (https://github.com/bytecodealliance/wit-bindgen/pull/183) and will add support for natively executing actual components once that is available upstream. Hope this is helpful!
In Spin – WebAssembly Framework

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.