Re: [w3ctag/design-reviews] WebAssembly Response API / Web Embedding (#167)

@domenic as FYI, since we talked about this a bit before the meeting.

I followed up on this issue in the Web Assembly WG meeting today at TPAC. Thanks @flagxor for the great overview and slides (would love pointers to those BTW). My objective was to review the question of whether JS was going to be considered as a first-class member of the binding proposal (we'd heard and derived from the [draft-in-progress](https://github.com/WebAssembly/host-bindings/blob/master/proposals/host-bindings/Overview.md) that JS objects might be out-of-scope--this was a mis-understanding of the non-goal line `Provide a general purpose managed object solution`). My takeaway was that the proposal is still trying to make generic JS object binding work.

Some notes: 
* I mentioned that I failed to see how basic [[Get]] might work when given an object_ref. Mark Miller noted Reflect.get, etc., that could be used by wasm to be the operation that performs the [[Get]], etc., calls when passing generic JS objects into wasm. 
* In talking with @lukewagner afterward, he described two scenarios: 
  1. two-way interop with generic JS objects. For example, handling an ‘any’ type and exposing conversion primitives like toUint32, etc., (basically the steps described in WebIDL’s binding)
  2. a wasm-only module: consider a wasm module that could be defined in a way that the UA pre-creates the DOM’s set of static entry-points into the wasm binding table, and therefore exposes all the DOM’s C++ call sites natively to wasm—taking JavaScript completely out-of-the-picture within that module. In other words, no GC or script realm is necessary (performance ensues). Caveat—no one (including me) has thought through what a JS-less wasm runtime environment would do, say, for example, when creating an iframe or new window or worker where new Realms are involved :-).



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/167#issuecomment-342685226