Guidance in exposing some APIs only off the main thread

[dontcallmedom]

Following up on #325, which has already quite a bit of background on this:
is it appropriate to use non-exposure of an API on Window as a way to force developers to not do things on the main thread?

That question has emerged in WebCodecs, WebRTC Encoded Transform, Media Capture Transform, WebNN, File API.

[dontcallmedom]

in case it helps, WebIDLpedia now gives information on exposure sets, in particular which interfaces are exposed only in a given exposure, e.g. for DedicatedWorker:

The following interfaces are exposed exclusively in [DedicatedWorker] realms:

• DedicatedWorkerGlobalScope
• MediaStreamTrackProcessor
• RTCRtpScriptTransformer
• RTCTransformEvent
• VideoTrackGenerator

[annevk]

I think the answer here is yes. E.g., see precedent of having synchronous I/O APIs only available in dedicated workers. (You typically do not want to block shared/service workers either.)

[dontcallmedom]

To @annevk's point, I think guidance in this space needs to recognize two distinct situations:

• blocking calls (e.g. synchronous I/O)
• triggers for expected-to-be CPU-compute-intensive processing that can make the main thread unresponsive (e.g. MediaStreamTrackProcessor, RTCTransformEvent) - the APIs themselves aren't blocking, but the type of operations they support can make the main thread janky because of their CPU usage.

I think there is probably no controversy around recommending against the 1st type.

There is obviously controversy on the 2nd type.

Part of it I think is that APIs of the 2nd type can be used on the main thread in a way that guarantees it would not impact it - e.g. MediaStreamTrackProcessor could be used to trigger GPU-only processing which presumably would have zero risk of slowing down the main thread.

(as discussed before, I'm the opinion that not exposing them on Window is a reasonable approach to avoiding footguns, but I also want to make sure we understand the problem clearly)

[alvestrand]

Note that all the five interfaces only available in DedicatedWorker are the hotly contested items in WEBRTC.
It's nice to see that there is no such pattern elsewhere.