[worklets-1] Worklet specs are generally impossible to integrate with WebAssembly without going through JS

[bzbarsky]

People are talking about adding IDL bindings for Web Assembly. Once that happens, specs that leverage IDL will start Just Working with Web Assembly without having to go through JS. But the Worklet specs typically assume that the objects they are handed are in fact JS objects, and directly manipulate them as JS objects.

For example, https://drafts.css-houdini.org/css-paint-api-1/#dom-paintworkletglobalscope-registerpaint step 5 assumes that the VoidFunction it was handed is an actual JS function and performs https://tc39.es/ecma262/#sec-get-o-p on it directly. Similar for step 9, step 13, steps 15-18.

Or for a different worklet spec, https://webaudio.github.io/web-audio-api/#dom-audioworkletglobalscope-registerprocessor makes that assumption in steps 3-7.

Or for a different one, https://drafts.css-houdini.org/css-animationworklet/#dom-animationworkletglobalscope-registeranimator steps 3-5 and step 7, same thing.

In all these cases, what is really desired is to pass in a "constructor" and then do the following:

1. Verify that it is in fact a constructor. Right now IDL has no way to express that, but see Define a callback constructor type whatwg/webidl#701.
2. Grab some data values from the constructor.
3. Grab .prototype from the constructor and validate that it's an object.
4. Grab some data values from the prototype.

I believe all of 2-4 are doable by defining appropriate IDL dictionaries. Unfortunately, that does not give a simple way to do item 1.

Per whatwg/webidl#701 (comment) maybe we should add explicit IDL syntax for "a thing that is like a JS class" which would allow defining the args the constructor takes, and which things one can get off the constructor and off the prototype. This could then get mapped to WebAssembly in some sane way. @lukewagner

In the meantime, it might be worth it to recast the various algorithms involved in a way that minimizes the ES dependency by taking the constructor (as a callback function for now), converting the corresponding ES object to a dictionary up front (to get all the bits from the constructor and prototype and whatnot in the form of IDL values), and then working with IDL values, not JS values. That should help flush out any other ES-specific bits hiding in these specs.

[tabatkins]

I am definitely in favor of doing things on IDL values rather than ES values, if for no other reason than IDL is way simpler and less confusing to work with imo. I've avoided doing some Worklet work already as a result, and am currently dreading having to write Custom Functions due to this...

[css-meeting-bot]

The Houdini Task Force just discussed WebAssembly and Workers, and agreed to the following:

• RESOLVED: Transfer over to webidl.

The full IRC log of that discussion

<TabAtkins> Topic: WebAssembly and Workers
<iank_> github: https://github.com//issues/945
<iank_> majidvp: This is a topic when boris looked at the animation worklet spec.
<iank_> majidvp: The concern is that most of the worklet specs, try to look at the class which is passed, and look at as if it was a JS object. E.g. access things w/ the prototype.
<iank_> majidvp: Doesn't sit will when the future when WASM can access these platform APIs. e.g. use IDL for these sections.
<iank_> majidvp: Issues there is no good way to check if something is a constructor.
<iank_> majidvp: I think tab was in agreement that we should do this.
<iank_> TabAtkins: The more stuff we do in WebIDL the better.
<dino> iank_: there have been issues on WebIDL in the past about exposing class constructors
<dino> iank_: is that in WebIDL yet?
<dino> heycam: i don't know
<iank_> heycam: I don't know.
<iank_> majidvp: Not sure yet.
<iank_> heycam: Having a webidl concept / type makes the most sense.
<iank_> iank_: what is web components doing?
<iank_> majidvp: Proposal is for them to also change their model.
<iank_> majidvp: Up to the web components folks to change it.
<heycam> https://github.com/whatwg/webidl/issues/701
<iank_> Rossen: Curious to know if they were ahead of us.
<iank_> heycam: Dropped an issue disucssing the webidl feature.
<iank_> Rossen: Any objects to transfer over to webidl?
<iank_> RESOLVED: Transfer over to webidl.
<dbaron> iank_: to clarify, when WebIDL stuff is ready

[domenic]

Let's fold this into whatwg/webidl#701.