WASM friendly dependencies

[olanod]

Not only to make maintenance easier but also to potentially enable WASM compilation what about using higher level HTTP and WebSocket abstractions like surf(I guess better for async-std environments?) or reqwest and for WS perhaps something like ws_stream_wasm at least for the client stuff?

[niklasad1]

Ok cool,

I think it's worth investigating for the client as you suggested, surf looks nice and ws_stream_wasm would require some conditional compilation because it only works for WASM.

[olanod]

For non WASM seems like ws_stream_tungstenite is the native equivalent

[niklasad1]

For non WASM seems like ws_stream_tungstenite is the native equivalent

After #171 we assume that a separate sender and receiver of the WebSocket stream exist which tungstenite-rs doesn't provide and it doesn't has support for async/await AFAIU).

Thus, it's a not an ideal library for us but the ws_stream_wasm/JS bindings implements Sink and Stream which is good.

[olanod]

The one I linked is from the same person behind ws_stream_wasm is not tungstenite-rs but something on top that implements the same interface.

[niklasad1]

#204 is merged which replaced hyper with surf. Thus, it now builds for WASM but I haven't tested it yet.

You have to disable the default-features and enable --feature wasm-client similar to what the CI does

[niklasad1]

Sorry, we had to revert #204 because surf brought in OpenSSL as a dependency which I didn't realize and it is not possible to disable it but when/if it becomes possible to enable/disable TLS on it (ideally with rustls), then we could move back to use surf again.

I left the branch open if you want to use still.

[olanod]

I think http-rs/surf#271 would be the PR to track for that

[athei]

I think http-rs/surf#271 would be the PR to track for that

I think that PR is merged and should be released by now?

[niklasad1]

Right, yeah thanks for letting us know but we still need tokio 1.0 support for this to work :(

Closing this issue in favor of #227