You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Generating WIT/WebAssembly Component for WebTransport server (WebAssembly Core Module) #1362
I spent about a year trying to get a WebTransport server working in the browser using Direct Sockets UDPSocket. With the help of a Zig programmer I realized that. Naturall
Zig WebTransport (TLS+QUIC state machine) server compiled to WASM standalone. From that WASM I compiled to JavaScript with wasm2js.
Now, I don't get all the hubbub about WebAssembly Components and WIT. Nevertheless I and interested in taking the WebAssembly Module and/or the asm.js output of wasm2js and creating a WebTransport "world" in WIT and thus port the WebTransport WebAssembly Core Module to WebAssembly Component Model, just for kicks, and because AFAICT there's no WebTransport WIT world already defined anywhere.
What do I need to do to take the existing WASM and/or JavaScript I have and create the WebAssembly Component thing?
Glad you're making progress but this to be clear, this issue is actually outside the scope of Jco -- we deal with WebAssembly components (or taking JS to build them, but that is outsourced essentially to componentize-js) and generate code to enable running in node (and experimentally the browser, but that implementation is pretty incomplete as of now).
That said, with regards to the work you're doing it seems like you may benefit from:
Assuming you have added implementations to interfaces generated by wit-bindgen, hooked that to your Zig code, you should get a component that works and adheres to the WIT world that you create.
I do not think you need to use wasm2js here, but if you insist then you'd have to convert your JS code to a component with a tool like componentize-js (or jco componentize).
Zulip is the right place to discuss/bat around ideas on this, rather than an issue on the Jco repo -- maybe if we had discussions enabled or something that might also work but for now we do not.
I'm going to close this out for now since it's not a Jco issue per-say, but we can keep discussing here or on Zulip
@vados-cosmonic Well, I don't need WASI for this. To me looks like there's a bug in wasm-tools. Unles you can explain what's wrong with this WIT. jco throws at the same place, because jco depends on wasm-tools
Glad you were able to make progress -- not sure why wasm-tools component new didn't work for you (that seems like a bug that should be filed upstream if the failure was legitimate), but if you were able to get what you wanted working, great!
Activity
vados-cosmonic commentedon Apr 6, 2026
Glad you're making progress but this to be clear, this issue is actually outside the scope of Jco -- we deal with WebAssembly components (or taking JS to build them, but that is outsourced essentially to
componentize-js) and generate code to enable running in node (and experimentally the browser, but that implementation is pretty incomplete as of now).That said, with regards to the work you're doing it seems like you may benefit from:
wit-bindgenfor C (example in the component model docs should help here), and building your Zig against the generated headerswasm-toolsafter embedding the WIT metadata (see README) (the p1 adapter codebase is upstream if you are curious)Assuming you have added implementations to interfaces generated by
wit-bindgen, hooked that to your Zig code, you should get a component that works and adheres to the WIT world that you create.I do not think you need to use
wasm2jshere, but if you insist then you'd have to convert your JS code to a component with a tool likecomponentize-js(orjco componentize).Zulip is the right place to discuss/bat around ideas on this, rather than an issue on the Jco repo -- maybe if we had discussions enabled or something that might also work but for now we do not.
I'm going to close this out for now since it's not a Jco issue per-say, but we can keep discussing here or on Zulip
guest271314 commentedon Apr 6, 2026
@vados-cosmonic Well, I don't need WASI for this. To me looks like there's a bug in
wasm-tools. Unles you can explain what's wrong with this WIT.jcothrows at the same place, becausejcodepends onwasm-toolsThat works.
This throws
guest271314 commentedon Apr 6, 2026
Seems to me that you folks should have a very basic WIT generating script that accepts WAT file
guest271314 commentedon Apr 6, 2026
Now,
jcowas able to generate the types. So I don't get whyjcoandwasm-toolsbroke on creating the component thingyvados-cosmonic commentedon Apr 6, 2026
Glad you were able to make progress -- not sure why
wasm-tools component newdidn't work for you (that seems like a bug that should be filed upstream if the failure was legitimate), but if you were able to get what you wanted working, great!