You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Start concrete comparison list against other current implementations #5
I really like the education benefit for the community of this project. I think the project has potential to educate router library and middleware authors to make their own implementation more robust and reach higher-quality implementations.
Thus, I would like to suggest a comparison list being added to the readme that outlines current "imperfections"/differences of other major router library providers.
I understand this list has potential for blame-gaming but I believe written in an informative and as-neutral-as-possible style it will actually help router and middleware authors to reach higher-quality implementations.
While writing, I got reminded of a website that has a similar comparison, but i can't figure out its address; something related to https://gomiddlewares.org or https://gohttphandlers.org ... which focused only on generic interface support.
That's a great idea. I was thinking about writing a blog post about this library, and perhaps a comparison with other projects attempting to solve this problem would be interesting.
That being said, I think other middleware implementors would probably benefit from simply using this library as it should already cover all use cases. But if they want to duplicate the effort I won't stop them, but they better get all the details right ;)
Activity
djui commentedon May 25, 2017
While writing, I got reminded of a website that has a similar comparison, but i can't figure out its address; something related to https://gomiddlewares.org or https://gohttphandlers.org ... which focused only on generic interface support.
felixge commentedon May 29, 2017
That's a great idea. I was thinking about writing a blog post about this library, and perhaps a comparison with other projects attempting to solve this problem would be interesting.
That being said, I think other middleware implementors would probably benefit from simply using this library as it should already cover all use cases. But if they want to duplicate the effort I won't stop them, but they better get all the details right ;)