Update comparison table

[nhooyr]

I tried my best to keep the comparison objective but please let
me know if you'd prefer anything changed.

Gorilla WebSocket compared with other packages

This comparison used to include golang.org/x/net/websocket but it has
been deprecated. Do not use golang.org/x/net/websocket in future projects.

See golang/go#18152

Another comparison of available Go WebSocket libraries is available at nhooyr.io/websocket

nhooyr.io/websocket

gorilla/websocket is 6 years old and thus very mature and battle tested.
On the other hand, nhooyr.io/websocket is much newer and attempts to
provide a more idiomatic, minimal and useful API for WebSockets.

	github.com/gorilla	nhooyr.io/websocket
RFC 6455 Features
Passes Autobahn Test Suite	Yes	Yes
Receive fragmented message	Yes	Yes
Send close message	Yes	Yes
Send pings and receive pongs	Yes	Yes
Get type of received message	Yes	Yes
Other Features
Well tested	Yes	Yes
Low level protocol control	Yes	No
Compression Extensions	Experimental	No
Read with io.Reader	Yes	Yes
Write with io.WriteCloser	Yes	Yes
Compile for Wasm	No	Yes
Use stdlib *http.Client	No	Yes
Concurrent writers	No	Yes
Configurable buffer sizes	Yes	No
Prepared messages	Yes	No
Full context.Context support	No	Yes
net.Conn adapter	No	Yes

[nhooyr]

I've also switched the comparison to use markdown syntax to make it easier to read.

[nhooyr]

I've also added a link to this comparison from my library's README.md.

[elithrar]

Thanks for this, and understand the effort, but I don’t think this makes sense.

The /x/net/websocket comparison does as many users look to the std lib for packages, and it’s large lack of API coverage is a real gap.

[nhooyr]

Thanks for this, and understand the effort, but I don’t think this makes sense.
The /x/net/websocket comparison does as many users look to the std lib for packages, and it’s large lack of API coverage is a real gap.

I'd have to disagree given the x stdlib package is already effectively deprecated and points users towards gorilla/websocket. This comparison makes it seem like only gorilla/websocket and the x/net libraries are the Go WebSocket libraries available but there is mine and gobwas/ws which include additional features that would be valuable to many users.

For example, my library can compile to WASM which is a requested feature here #368

It implements a net.Conn wrapper which many users have told me they found very useful as it makes it easy to interoperate with other networking libraries and eases the transition from golang.org/x/net/websocket.

I also think the context.Context support and concurrent writing is a big one that users of this library have to handle themselves. E.g. see #87.

Likewise, as soon as WebSockets over HTTP/2 can work with the Go stdlib, I'll be implementing them very quickly as my library uses the stdlib *http.Client directly. gorilla/websocket will have a harder time as it exposes the direct net.Conn. Likewise with the WASM support. It also means I do not have to implement things like #516.

There's also the wspb/wsjson subpackages which reuse buffers automatically.

My library also makes it simpler to deal with write only WebSocket connections and pings. See #492 for gorilla issue regarding this.

To summarize, my point is that there is real demand for the features my library implements and it's evident in the gorilla/websocket issue tracker. Rather than duplicate every feature here, it makes more sense to point users to my library if they're looking for these features. Likewise with gobwas/ws but they'll see that in my libraries's README.md so I didn't include it here but I can if you'd like.

I'm not saying everyone should switch, I've made it clear in this comparison and the one on my repo that gorilla/websocket is the mature and battle tested option and if that's what you're looking for, gorilla/webosocket is the choice.

[nhooyr]

I can clarify the comparison further if that would help.

[elithrar]

No - I understand where you are coming from. I’m happy to have a list of alternative libraries as one-liners (and links); I’m not interested in maintaining documentation in this package for other libraries. We can agree to disagree here, but this won’t be merged as-is.

…

On Sat, Sep 28, 2019 at 5:07 PM Anmol Sethi ***@***.***> wrote: I can clarify the comparison further if that would help. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#543?email_source=notifications&email_token=AAAEQ4FPDOR6IUK3TDICB5LQL7WTHA5CNFSM4I2DUECKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73EV6Q#issuecomment-536234746>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAEQ4BTCA4MMLYC32SMGL3QL7WTHANCNFSM4I2DUECA> .

[nhooyr]

I'm happy to maintain it. See my comment in #370

For now I'll follow up with a PR with just the links.

Thanks!

[elithrar]

Thanks.

…

On Sat, Sep 28, 2019 at 5:29 PM Anmol Sethi ***@***.***> wrote: I'm happy to maintain it. See my comment in #370 <#370> For now I'll follow up with a PR with just the links. Thanks! — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#543?email_source=notifications&email_token=AAAEQ4GZTQCIGHVUKPH2YILQL7ZG3A5CNFSM4I2DUECKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73E6DQ#issuecomment-536235790>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAEQ4GA6M7RVZNI5Q6O4S3QL7ZG3ANCNFSM4I2DUECA> .