Include performance comparison with gorilla/websocket

[nhooyr]

Should add to the comparison their performance should not differ significantly backed up with benchmarks.

Should also mention how large each implementation is and the effect of this on docs and long term stability.

Should also mention that gorilla/websocket is effectively unmaintained at the moment: gorilla/websocket#370

Pure conjecture but part of it is likely the sprawling API of the library makes it hard to maintain.

[nhooyr]

I think there are other improvements that can be made as well, especially with the Design justifications listing.

[ghost]

I've been helping out with Gorilla for several months. I have yet to see any evidence that the "sprawling" aspect of the API contributes to maintainability issues.

Gorilla is looking for a new maintainer. That's not the same thing as being unmaintained.

[nhooyr]

@stevenscott89 I absolutely agree, I was just writing thoughts down, will not include that in the comparison.

[nhooyr]

I think the current comparison is fair and performance wise, the only big difference is this library spawns 2 extra goroutines for every connection to support contexts natively, but that shouldn't impact most apps negatively. So I'll add that and then close.

I once again apologize for my unfair comment about Gorilla's maintainability @stevenscott89.