"Another WebSocket library" is a fair thing to be skeptical of. Go already has several good ones, some of them excellent at exactly what they set out to do. So before explaining why wshub exists, the honest version of this post has to start somewhere else: what's actually already out there, and what each one leaves for you to build yourself.
Every Go WebSocket server starts the same way. You pull in gorilla/websocket
or nhooyr.io/websocket, write an Upgrade call, spin up a goroutine that
reads frames in a loop, and it works. You broadcast a message by iterating a
map[*Client]bool and calling conn.WriteMessage on each one. Twenty lines,
a working demo, and a reasonable belief that the hard part is behind you.
It isn't. The hard part starts at the traffic your demo never saw: a client that stops reading, a deploy that needs to happen without dropping connections, a second replica that has no idea the first one exists. None of that is in the WebSocket RFC, and none of it is optional once real users are on the other end of the socket.