-
Notifications
You must be signed in to change notification settings - Fork 304
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include performance comparison with gorilla/websocket #75
Comments
I think there are other improvements that can be made as well, especially with the Design justifications listing. |
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. |
@stevenscott89 I absolutely agree, I was just writing thoughts down, will not include that in the comparison. |
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. |
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#370Pure conjecture but part of it is likely the sprawling API of the library makes it hard to maintain.The text was updated successfully, but these errors were encountered: