Compile for WebAssembly

[nhooyr]

@albrow I saw you in issue gorilla/websocket#432 (comment)

If you'd like to contribute the necessary improvements to this library, I'd be more than happy to help, review and merge your changes.

[albrow]

@nhooyr the API for nhooyr/websocket is much smaller than gorilla/websocket and more closely resembles the JavaScript API. It looks doable.

My main motivation for a WebAssembly-compatible WebSockets library is to support running libp2p/go-ws-transport in the browser. I have already made that possible with libp2p/go-ws-transport#51. It's hard to justify spending time on a different approach when we already found one that works.

That said, we could potentially reduce the maintenance burden for libp2p/go-ws-transport by changing it to use this package and abstracting away the Wasm/JavaScript related code. I don't know how open the libp2p team would be to that idea. If we were to go this route, another important thing to consider is browser compatibility and backwards compatibility for anyone still using gorilla/websocket.

Have you done any testing to see if this package is compatible with browsers and/or gorilla/websocket?

[nhooyr]

That said, we could potentially reduce the maintenance burden for libp2p/go-ws-transport by changing it to use this package and abstracting away the Wasm/JavaScript related code. I don't know how open the libp2p team would be to that idea.

That would be fantastic.

backwards compatibility for anyone still using gorilla/websocket.

This would be unfortunate but I don't see a good way around it. The libraries are fundamentally different.

I meant in terms of API, but yes they both can talk to each other just fine.

Have you done any testing to see if this package is compatible with browsers and/or gorilla/websocket?

Yes, I've done extensive research and experimentation. You can see it all in the issue history. I've read gorilla/websocket's source and issue tracker nearly completely.

We use this library at https://coder.com, it fully passes the autobahn test suite (which tests compatibility between WebSocket implementations), has a solid array of tests and 35 or so unique cloners a day (400 clones usually) so it is used in the wild.

[nhooyr]

Oh my bad, I misread your response. You're asking whether it's compatible with the browser API.

Definitely only a subset would work but I'll take a closer look tonight and get back to you.

[albrow]

@nhooyr Sorry I wasn't super clear. I'm actually asking about connection compatibility. Can you dial from a browser to a server that is using nhooyr/websocket? (It sounds like the answer is yes). Can you dial from nhooyr/websocket to gorilla/websocket and vice versa?

[nhooyr]

Yea, will work fine.

[nhooyr]

The API's that will need to be removed when compiling for WASM:

• Accept as you cannot accept WebSocket's on browsers (unless WASM also works on nodejs and you can accept there?)
• DialOptions's HTTPClient and HTTPHeader
• The streaming APIs
• SetReadLimit
• Ping
• CloseRead
• Export then unexpected status codes (they're unexpected because they don't make sense for Go)

It'd be an extremely stripped down API.

[nhooyr]

I'm not sure if this will be worth it given those considerations. It'd require refactoring the code quite awkwardly wherever the WASM splits are required and involve quite a bit of complexity. I wonder if it'd be better to have a sub package /wasm that implements a subset of the API for WASM.

[nhooyr]

So I'm convinced this is a good idea and shouldn't be too hard this weekend.

[nhooyr]

Will ask https://github.com/gopherjs/websocket to be deprecated once this is done.

[nhooyr]

Related: gopherjs/websocket#28