Add a Global type that abstracts over Window and WorkerGlobalContext

[allsey87]

I would like to consider the pros and cons of adding a Global type to js-sys that is returned from js_sys::global(). This global type would be a wrapper over bindings to either a Window or WorkerGlobalScope and would provide the intersection of the two APIs.

The motivation for this is that several projects, most recently Bevy (bevyengine/bevy#12134), want to be agnostic over whether they are running in a worker or in the main window. This has led to duplication of probing code in numerous code bases which tries to figure out at, often on each innovation, whether the global scope is a window or a worker global scope.

The argument against this is that js-sys should be bindings only. I would however counter that argument with the fact that js-sys does go beyond just bindings. For example, it provides iter-operation with Rust iterators and bindings such as Uint8Array have special methods like to_vec for efficiently copying data into wasm memory.

[allsey87]

Although I feel that this could fit into js-sys, the alternative would be to create a lightweight crate gloo-global which has a single dependency on js-sys and is dedicated to this abstraction.

[daxpedda]

I would however counter that argument with the fact that js-sys does go beyond just bindings. For example, it provides iter-operation with Rust iterators and bindings such as Uint8Array have special methods like to_vec for efficiently copying data into wasm memory.

This is limited to optimization that can't be done without the help of wasm-bindgen/js-sys.

See #1046 for previous discussion on this.

---

In any case, a Global type like you are describing would not work unfortunately, as Window and DedicatedWorkerGlobalScope are not the only global scopes that exist. Think about AudioWorkletGlobalScope, which shares very little if any interface with others.

The only viable solution I can think of is to expose the WindowOrWorkerGlobalScope mixin. But this requires a bigger discussion on how and if we want to expose mixins in web-sys.

[daxpedda]

fetch is not available in e.g. AudioWorkletGlobalScope.

[jbms]

If the same webassembly module needs to load both in a regular worker and an audio worklet, then the JavaScript could arrange to substitute for the import a stub function that throws an exception when running in an audio worklet.

[daxpedda]

That exception has to be caught and delivered to the user, e.g. returning a Result from the fetch() function, again, returning back to square one.

To be clear, this all sounds like convenience functions to me, which was already discussed as not really having a place in bindings.

[allsey87]

While I can understand that there is no ideal solution to this problem for the time being, I don't feel like that argument about convenience functions is particularly strong. To the best of my knowledge, both web-sys and js-sys have convenience functions to ease interop with Rust. For example, js-sys has additional methods to bridge the gap between Javascript and Rust iterators...

[daxpedda]

While I can understand that there is no ideal solution to this problem for the time being, I don't feel like that argument about convenience functions is particularly strong.

Exactly because there is no ideal solution we should leave this to an outside crate, like discussed in #1046. I'm not saying that convenience functions are something to stay away from in general, but its not in scope for wasm-bindgen & co as defined by the original authors.

To the best of my knowledge, both web-sys and js-sys have convenience functions to ease interop with Rust. For example, js-sys has additional methods to bridge the gap between Javascript and Rust iterators...

As mentioned in #3863 (comment):

This is limited to optimization that can't be done without the help of wasm-bindgen/js-sys.

---

#1046 contains a lot of discussion on this topic already that I would not like to repeat here.

[jbms]

Per this discussion I created this pull request in gloo-net: rustwasm/gloo#474 where I just defined a separate global binding for fetch rather than using the web_sys bindings for fetch which added a lot of complexity and inefficiency.

Note that the gloo-timers crate already similarly defines separate global bindings for setTimeout and related functions rather than using the ones in web_sys.

It seems to me, though, that in all cases direct global bindings of everything in the WindowOrWorkerGlobalScope mixin would be preferred over the existing bindings in web_sys.

As far as making fetch return a Result --- that would probably be undesirable but there are a few alternative options: (1) just make the WebAssembly module fail to load at all (due to undefined import) when loaded in an audioworklet --- I expect for most users it would be preferred to use this solution over something that adds overhead (2) make the audioworklet fetch stub return a rejected promise (3) make the audioworklet fetch stub cause an unrecoverable error (e.g. by throwing an exception that won't be caught).

[daxpedda]

Please correct me if I'm wrong, but it sounds to me like this is coming from a place of "checking the global context adds too much overhead". If that is the case I would very strongly recommend you to measure and report that overhead, my guess would be that a call to fetch() adds so much overhead that any overhead introduced by basic control flow would be very insignificant.

I also strongly disagree with just ignoring the fact that a global context exists and is relevant to the user, throwing unrecoverable errors or modifying Web API functionality where a bindings crate should faithfully let users access known and specified APIs sounds like a really bad user experience to me.

It would help a lot if we first agree on a motivation before proceeding with a solution.

---

That said, I very much sympathize with the motivation stated in the OP, which is why I think exposing the WindowOrWorkerGlobalScope mixin would be a good solution that doesn't break the scope of wasm-bindgen & co.

Additionally some way to simplify determining which global context the user is present in so we don't have to duplicate this code literally everywhere in the ecosystem sounds great as well, which probably isn't something specific to the global context.