
Show HN: A minimal and idiomatic WebSocket library for Go - nhooyr
https://github.com/nhooyr/websocket
======
hardwaresofton
Somewhat unrelated to the actual package but I find that properly
written/considered comparison (why X package instead of Y?) sections are a
strong indicator of library/package quality, and this library passes that
test:

[https://github.com/nhooyr/websocket#comparison](https://github.com/nhooyr/websocket#comparison)

~~~
epynonymous
agree with your point, but i don't see any performance comparisons, at the end
of the day, i'm looking at performance and stability as a leading factor for
why i choose a particular library over another. obviously there are other
factors like documentation, how well a library is maintained (i.e. any
checkins in the last few weeks because there are bound to be bugs), popularity
(i.e. github stars), and generally the interface of the library, is it
methodical or cumbersome?

~~~
nhooyr
I updated the comparison, I think you'll find it more compelling in terms of
stability and performance.

To summarize, they're about equal in terms of performance but I'd argue my
library wins on stability and maintainability as the minimal API enables a
tiny codebase, which means less docs, less tests and most importantly, less
bugs.

Furthermore, the future of gorilla/websocket is uncertain.
[https://github.com/gorilla/websocket/issues/370](https://github.com/gorilla/websocket/issues/370)

[https://github.com/nhooyr/websocket#gorillawebsocket](https://github.com/nhooyr/websocket#gorillawebsocket)

------
papaf
I converted a program today from Gorilla websocket to this library.

The code is much simpler although I still have to clean up my error messages
after the websocket shuts down and the context is Done.

~~~
nhooyr
Glad to hear it :)

------
ben_jones
What are the practical advantages of websockets instead of long-polling? As
someone who has implemented both I've found much more success with long
polling, but maybe because I haven't used a library as solidly written as this
one.

Seriously, at short glance this seems like a well-written library, well-
documented, solid looking table-driven testing, and a thoughtful write-out of
comparable libraries. Only recommendation would be a link/badge indicating
test coverage through a UI like coveralls.

~~~
chessturk
I'm waiting for a lib like Phoenix Channels with a js client that starts with
WebSockets and falls back to long polling if things like firewalls get in the
way. I actually found Phoenix when trying to solve that usecase in go.

I feel like because of Go's concurrency model, a standalone version of Phoenix
Channels (without all the MVC stuff) would be possible to implement.

Phoenix:
[https://hexdocs.pm/phoenix/channels.html](https://hexdocs.pm/phoenix/channels.html)

~~~
QuinnWilton
Phoenix channels don't really depend on MVC. It's common to make use of them
in MVC apps, but they can be used standalone.

I'm using Phoenix channels as a PubSub implementation in production, entirely
separate from any web framework or HTTP request handling.

As for the transport itself, Phoenix channels do have native support for both
websockets and long polling, but I'm not sure offhand if it automatically
falls back when websockets aren't available.

------
fabioyy
any benchmarks?

~~~
nhooyr
Not yet but in comparison with gobwas/ws, this library is definitely slower
but not by much, at least you won't notice until you're serving a million
connections.

Compared to gorilla/websocket, they're about the same.

I opened
[https://github.com/nhooyr/websocket/issues/75](https://github.com/nhooyr/websocket/issues/75)

------
dvt
Back when http was part of the standard library (I think it was eventually
pulled out?), I was building a long polling server with Go and had to fix some
stuff to make sure it worked properly. I can hardly believe I wrote some of
these patches nearly 10 years ago[1].

With that said, I'm glad to see the Go ecosystem continue to grow.
Unfortunately, I haven't used the language for much (corporate jobs were
always Java, startup jobs were always JS -- and recently, it's been Python
everywhere).

PS: I still brag about Rob Pike & Russ Cox approving my patches ;)

[1]
[https://github.com/golang/go/issues/93](https://github.com/golang/go/issues/93)

~~~
enitihas
http is still a part of the standard library, and having used it recently, I
find the API good enough.

~~~
mappu
Although the package was moved from "http" (in the linked example) to
"net/http" in commit de03d502 in Nov 2011, four months before 1.0 and its
compatibility promise.

