Initial design sketch for an revised JS-API

[eqrion]

I'm presenting on Mozilla's prototype implementation which is based off of this, so I wanted to have it publicly accessible somewhere. It needs a couple more iterations before it's ready for detailed review. High-level feedback is welcome though.

[ValorZard]

I have a few dumb questions

1. What parts of the Web APIs DON'T fall under WebIDL?
2. When interacting with javascript types and functions through webidl, are those objects still garbage collected, or does the wasm component take full ownership of them. If I'm writing a rust WASM component for the web, and I get access to a Button, is that button garbage collected? And if so, how? Can I "free" that button in the Rust component and accidentally remove it from the browser somehow?

[eqrion]

@ValorZard

Apologies for the delay, I was rewriting most of the explainer for a new approach. I'm less convinced now that specifying this in terms of WebIDL is the right approach and so I'm switching back to this being a JS-API.

I believe we can get good performance for web API calls by designing value conversions such that JS script cannot intercept them when a web API is imported directly. The new approach attempts this, and it's not as bad as I thought it would be.

It's not quite ready for review but is closer now.

I have answers to your questions, but they're in terms of the discarded draft so I'm not sure it's relevant anymore.

[ValorZard]

@eqrion so, something that i've run into as a Rust WebAssembly enjoyer is that even though on paper Rust compiled to webassembly should be faster than javascript, in practice they're about the same speed, and in fact Rust can be slower compared to javascript when it comes to using apis like WebGPU or WebGL2.
For example (and don't quote me on this), I think the Bevy game engine's web renderer is slower than three.js because three.js is natively written and optimized for javascript.

will this new api fix this?