Blocking APIs in Workers?

[ricea]

From a usability perspective, a blocking API is very attractive. However, the impact on interactivity would be unacceptable on the main thread.

An interesting possibility is to provide a blocking API only in workers.

Maybe something like

[Exposed=Worker] static Uint8Array blockingCompress(DOMString format, BufferSource input);

See also #8 for an equivalent non-blocking method and #37 for motivation.

[nicjansma]

One place where a blocking API could be helpful is for cases of using compression in unload, i.e. beaconing data for analytics usage. RUM libraries like boomerang.js hook into pagehide etc, and we often beacon data at the end of the page session.

However, we don't know of an easy way to utilize the Compression Streams API in this scenario as the async nature means we won't get the compressed bytes for passing to .sendBeacon() in the pagehide handler in time -- the page has unloaded waiting for the callback/await.

I've added an idea to the Beacon API tracker to see if it could compress on its own w3c/beacon#72, but it could also possibly be solved with a sync API here. Though having the sendBeacon() API allow for this may be more ideal, as it it could handle the compression off-thread and off the critical path of the page unloading.