Scott Waye (Apr 19 2023 at 12:50): Scott Waye (Apr 19 2023 at 12:50):I was thinking about maybe doing a bit more source codegen for c# (I did a bit of playing with witx-bindgen some time back), and want to ask the question, how much commonality is there between the source code generator in wit-bindgen and the one in wasm-bindgen, and the one that was in witx-bindgen ?
bjorn3 (Apr 19 2023 at 13:37):wasm-bindgen is entirely unrelated to wit/witx. It is exclusively for rust code and running inside a javascript engine.
bjorn3 (Apr 19 2023 at 13:38):As far as I understand wit is being standardized with the wasm component model. Witx doesn't work with the wasm component model.
Scott Waye (Apr 19 2023 at 13:59):Yes, I just wondered if they had the same authors and might have been similar designs. I know wasm-bindgen is for rust, but it's page does say "and it's hoping that over time as this tool stabilizes that it can be used for languages like C/C++" https://rustwasm.github.io/docs/wasm-bindgen/ Maybe that's out of date.
Scott Waye (Apr 19 2023 at 14:12):I like the idea of making wasm-bindgen, "bindgen" for c# but not if its going to be 100% dead code in a years time. As I understand it wasm-bindgen was a "sort of half polyfill for features like the host bindings proposal" which is replaced by the component model. There is a relation here isn't there?
Alex Crichton (Apr 19 2023 at 14:22):I wrote most of wasm and wit bindgen and I'd recommend wit bindgen for the component model. The two have somewhat similar designs but not really enough to substantively share anything. The input to both bindings generators is very different.
Also don't hold your breath for C and C++ support in wasm-bindgen, those docs are very outdated
Scott Waye (Apr 19 2023 at 15:43):Thanks, I wonder, could you take the wasm-bindgen's web IDL frontend to create a Wasm module, or object file out of web-sys, define the functions you want from Web IDL to wit, create a tool to marshal the wit calls to Web IDL, then use the the wit source gen in the source language?
Scott Waye (Apr 19 2023 at 15:44):So the source language talks component model, but it is mangled into Web IDL using another generator, then leverage the wasm-bindgen WebIDL frontend to get to JS
Alex Crichton (Apr 19 2023 at 15:45):Well, what's within the realm of possibility is only limited by how big we can dream.
What I can say though is that from a practical side of things that would likely be quite a lot of work with quite a few compromises along the way with a lot of overlap with existing work in other areas. Probably could be done, wouldn't necessarily recommend doing so though.
Scott Waye (Apr 19 2023 at 15:45):mm, ok, thanks
Scott Waye (Apr 19 2023 at 15:47):What are the "other areas" you are thinking of? As far as I can tell using wit/component model to get to the DOM is in pretty early stages in Chromium at least
Scott Waye (Apr 19 2023 at 15:48):I do a lot of dreaming :-)
Alex Crichton (Apr 19 2023 at 16:02):There's quite a lot of overlap between things like WASI, the component model, WebIDL, what wasm-bindgen does, and web-sys. Not to say there's complete overlap of course, as WASI isn't planning on adding a DOM any time soon.
One day this is something I'd like to see as well, basically a componentized version of web-sys with a bindings generator that automatically hooks up everything in the same manner that wasm-bindgen does today. I haven't thought much about it beyond this though
Notification Bot (Apr 19 2023 at 16:13):Scott Waye has marked this topic as resolved.
DougAnderson444 | PeerPiper.io (Aug 13 2023 at 10:34):Alex Crichton said:
basically a componentized version of web-sys with a bindings generator that automatically hooks up everything in the same manner that
wasm-bindgen
:heart_eyes:
Giving us a way to build reusable, composable wasm Websites components, executed in a sandboxed way? Do we realize how powerful this would be? Especially in terms of limiting data exfiltration on the web!
DougAnderson444 | PeerPiper.io (Aug 13 2023 at 16:30):Hi @Luke Wagner The wasm-bindgen repo says
Designed with the "Web IDL bindings" proposal in mind. Eventually, there won't be any JavaScript shims between Rust-generated wasm functions and native DOM methods. Because the wasm functions are statically type checked, some of those native methods' dynamic type checks should become unnecessary, promising to unlock even-faster-than-JavaScript DOM access.
...which is linked here with your name on it.
I see that issue has deferred to the Component Model, which is great and I am wondering if the goals are the same: interface directly to the DOM and eventually skip the JavaScript middleman?
I asked because of what @Alex Crichton says above -- one day it would be great to have web-sys component that interfaces to the DOM. Is this on the roadmap anywhere? I am very excited by the prospect of being able to manipulate the DOM from inside a WIT Component!
Ramon Klass (Aug 13 2023 at 22:30):the plan is to at some point have a dom world you can import in your components, but remember that means browsers must natively support component model, which means it requires at least a 1.0 release, not a preview2 soon to be preview3. Judging by the roadmap Bailey showed last month, I would guess work on browser support of the final component model specification can start early next year, but that is pure speculation
Pat Hickey (Aug 14 2023 at 15:54):the component model doesn't require native support by browsers, though that would be nice to see one day. it can run in js engines today via jco
Ramon Klass (Aug 15 2023 at 12:23):their goal was to have native browser apis, as in wasi directly calling C functions, circumventing js entirely
Ramon Klass (Aug 15 2023 at 12:24):that's the thing where I'm pretty sure you can't even start work on it until a 1.0 component model
Ramon Klass (Aug 15 2023 at 12:28):though I'd love to be wrong :) combining wasm-bindgen with wit-bindgen and browsers exporting dom calls through component interfaces would be a big milestone for wasi everywhere, people still are very biased against wasm frontends since there are a lot of rumours about the complexity of converting values between wasm and js
Pat Hickey (Aug 15 2023 at 15:35):wasm shipped as an mvp in browsers before it was 1.0
Pat Hickey (Aug 15 2023 at 15:41):the complexity of converting values between wasm and js has definitely been an issue that has prevented wasm from being used more widely. the component model and all the wit tooling has been heavily informed by both the successes and failures of wasm-bindgen - alex was a leader on wasm-bindgen and has been the leader in defining what wit is and how the tools work.
DougAnderson444 | PeerPiper.io (Aug 15 2023 at 16:37):The wasm-bindgen readme says
Eventually, there won't be any JavaScript shims between Rust-generated wasm functions and native DOM methods.
which would mean we would be able to skip over the javascript conversion all together (=awesome)
The idea I was wondering about was making a WIT world with DOM import functions, then passing the WIT a handle to the DOM functions. I'm pretty sure that would work in present day, yes?
Ramon Klass (Aug 15 2023 at 16:42):I think you could do that with jco already, but I'm almost sure jco would still just call the dom updates in js code and send you back the responses, it could be used to prototype a dom wit but ultimately browsers need to implement that world's host in their C code
Lann Martin (Aug 15 2023 at 17:24):You can do that today, but only for functions that only work with "value types" (think: stuff you can represent in JSON). Once resources are implemented in jco I believe it should be fairly straightforward to implement at least large parts of the DOM APIs.
DougAnderson444 | PeerPiper.io (Jan 26 2024 at 19:42):Linking this here for eveyrone, @Scott Waye
https://github.com/MendyBerger/webidl-wit#conversions-from-webidl-to-wit-types
Last updated: Nov 22 2024 at 16:03 UTC