Browser Support?

[zicklag]

Hey there! Would you be open to supporting browsers behind a feature flag that uses wasm-bindgen?

[complexspaces]

Hey there,

I'm not particularly opposed to inclusion of browser support, but I do have a few questions about how it would be implemented based off my current knowledge of JS/Rust interoperability:

• How will users deal with the requirement of --cfg=web_sys_unstable_apis being provided to via RUSTFLAGS to access the relevant APIs in web-sys?
• What is the plan to handle the inherent async nature of everything that calls into browser APIs? As it is today, the whole crate has a synchronous API.

[daxpedda]

• How will users deal with the requirement of --cfg=web_sys_unstable_apis being provided to via RUSTFLAGS to access the relevant APIs in web-sys?

This can be circumvented by not relying on web-sys but wasm-bindgen and just defining your own imports that are not gated behind --cfg=web_sys_unstable_apis.

• What is the plan to handle the inherent async nature of everything that calls into browser APIs? As it is today, the whole crate has a synchronous API.

Ultimately I think this is gonna be the dealbreaker. There is a synchronous API for writing to the clipboard: execCommand('copy'). But it doesn't really work the way we need it to.

[zicklag]

Ultimately I think this is gonna be the dealbreaker. There is a synchronous API for writing to the clipboard: execCommand('copy'). But it doesn't really work the way we need it to.

Ah, bummer. I didn't think about the async nature. In my use-case it didn't really matter because I could set or get the clipboard as an async call and just not wait for the promise to finish.

But for users who use the native API and expect it to behave the same, that would be confusing if they couldn't set the clipboard and have an immediate read reflect the new clipboard contents when on web.

For now I'll just workaround in my app with WASM bindgen. Thanks for the replies!