lukewagner
commented
1 week ago The goals of this proposal have shifted along with the name of the proposal as our understanding of the problem space has improved and the usage of wasm has expanded beyond the browser. E.g., there were some experiments a few years back by the Emscripten team showing that, at least for the WebGL workloads that they were measuring, the actual overhead of JS glue code wasn't significant enough to motivate continued work on what was then called "Web IDL Bindings". While I think the component model could indeed still be used to optimize away JS glue code when calling from wasm into the browser, that's no longer the main driving goal for the C-M (see Goals.md and UseCases.md for what are). In the meantime, better browser integration has been happening incrementally both in core wasm (with the addition of externref) and the JS API (see js-promise-integration and js-string-builtins), all of which can be used to optimize the generated glue code by the Component Model's browser polyfill, jco. Based on the last in-person CG meeting, I expect there will be further incremental optimizations motivated by optimizing away significant sources of overhead, especially copying of data into and out of streams and WebGPU buffers.
I am lost with current proposals. As I know Interface types proposal was created for direct WebAPI calls from WebAssembly. (Answer from Emscripten team https://github.com/emscripten-core/emscripten/issues/15710#issuecomment-987263141 )
But it was renamed to component model and slowed down? How WebAssembly WebGL applications supposed to be faster than pure JS?