wasm support

[johanhelsing]

I'm looking for a socket io client crate that works on both wasm and native. Is this something you'd want to add?

[1c3t3a]

What exactly do you mean by working with Wasm? Right now you could compile the crate to Wasm using Emscripten's runtime: cargo build --target wasm32-unknown-emscripten. What you mean is probably interoperability with JS via wasm_bindgen. The problem here is, that you then usually compile to the target wasm32-unknown-unknown, which doesn't compile with stdio things like threads and networking (stuff that this crate uses extensively). A possible solution would be to add #![cfg(target_arch = "wasm32")] flags to those functions and sub it with the bindings from web-sys. I generally would like to see that this crate works with Wasm, also because I think that this would be a use case.

[johanhelsing]

Yes, the use case I have is that I want to be able to run the same code without modifications both in the browser and as a native application.

[1c3t3a]

Ups sorry! I think in order to get this started one could look at how reqwest (the http library used here) implemented Wasm support (mainly in src/wasm or src/lib.rs). We would also need to somehow factor out the thread that starts the polling cycle and threads that start the callback (currently through the spawn_scoped! macro). Async support before this (see Roadmap.md) would come in handy because async is supported by the browser.

[1c3t3a]

If looked further into this and WASI could be an option as well. WASI provides sort of a normal standard library for WebAssembly and is both supported by the browser and the most common runtimes. It is accessible via the wasm32-wasi target. It provides a std implementation, but yields unimplemented!() calls on the functions unavailable in the browser.

[piaoger]

A build error related to openssl is found while I am trying to use it in an app built on wasm and rust.

[1c3t3a]

Yes, this is not yet implemented. There is no support for the WASM target yet.

[piaoger]

Yes, this is not yet implemented. There is no support for the WASM target yet.

Got it :) You have aldeady done great job.
It 's nice to see more and more frontend frameworks wrintten in rust.

[philipp1992]

any update on this? i would like to use socketio client within leptos but got the same error with wasm

[ulvido]

I am ok if only can compile to wasm only so I can use it with my browser extension.

currently getting error for getrandom crate when compiling with wasm-pack.

wants to be added js feature

[BrianWiz]

WASM support would be excellent, it's definitely a nice use case. Rust end to end is powerful. It's been a few years since this ticket was created, I wonder what the limitations are now?

I'm not sure where to start if I were to help with this

[1c3t3a]

I have no knowledge about whether this has gotten easier. I assume it got simpler, since a few dependencies probably started to support wasm behind some flag, so we could use them instead of switching them out for our own logic.

Regarding leptos that was mentioned by @philipp1992: I assume this needs the wasm*-unknown-unknown targets, which don't provide any standard library functionality. All references to this in this crate would need to be feature-gated and replaced with special WASM handling code.

As for concrete steps on how to get there (just my ideas, take it with a grain of salt):

1. Start compiling this crate with with --target wasm32-unknown-unknown and see which dependencies fail. Go through all of these failures and find a solution to them. Solutions can be:
   1.1 If the library supports wasm32-unknown-unknown behind a feature flag, enable it (like shown in the error message for getrandom).
   1.2 Replace the library with an alternative that supports wasm.
   1.3 (If applicable) Replace the library with a call to a separately compiled WASM module (inside an extern block). This could e.g. be a solution for openssl if we want to call to https://github.com/voltbuilder/openssl-wasm.
   1.4 Reimplement the functionality manually (probably not wanted for most things).
2. After all dependencies are fixed, you will see the build errors in this crate. Again, we would need to go and fix all of them step-by-step and replace with wasm compliant calls (probably most of it should go to web-sys).

I think this is quite a heavy lift but I agree that it would be awesome to have it!! I am open to mentor someone e.g. through regular calls and PR review, but I unfortunately don't have the time to work on this myself.