<story><title>Show HN: Drogon – A C++14/17 based high performance HTTP application framework</title><url>https://github.com/an-tao/drogon</url></story><parent_chain><item><author>KirinDave</author><text>This is cool, and I like it. Very Haskell like, which is a compliment in my book.&lt;p&gt;But one thing that surprises me is that folks are essentially sleeping on HTTP&amp;#x2F;2. HTTP&amp;#x2F;2 is just a hell of a lot better in most every dimension. It&amp;#x27;s better for handshake latency, it&amp;#x27;s better for bandwidth in most cases, it&amp;#x27;s better for eliminating excess SSL overhead and also, it&amp;#x27;s kinda easier to write client libraries for, because it&amp;#x27;s so much simpler (although the parallel and concurrent nature of connections will challenge a lot of programmers).&lt;p&gt;It&amp;#x27;s not bad to see a new contender in this space, but it&amp;#x27;s surprising that it isn&amp;#x27;t http&amp;#x2F;2 first. Is there a good reason for this? It&amp;#x27;s busted through 90% support on caniuse, so it&amp;#x27;s hard to make an argument that adoption holds it back.</text></item></parent_chain><comment><author>HippoBaro</author><text>The reason is that HTTP&amp;#x2F;2 will be short-lived. Most of its potential (protocol multiplexing, mainly) is wasted because it still runs over TCP&amp;#x2F;IP. HTTP&amp;#x2F;3 will correct that with QUIC. I think we can except HTTP&amp;#x2F;3 to really see widespread adoption.
HTTP&amp;#x2F;1.1 will remain ubiquitous though because there&amp;#x27;s a gazillion box that only speaks that.</text></comment>
<story><title>Show HN: Drogon – A C++14/17 based high performance HTTP application framework</title><url>https://github.com/an-tao/drogon</url></story><parent_chain><item><author>KirinDave</author><text>This is cool, and I like it. Very Haskell like, which is a compliment in my book.&lt;p&gt;But one thing that surprises me is that folks are essentially sleeping on HTTP&amp;#x2F;2. HTTP&amp;#x2F;2 is just a hell of a lot better in most every dimension. It&amp;#x27;s better for handshake latency, it&amp;#x27;s better for bandwidth in most cases, it&amp;#x27;s better for eliminating excess SSL overhead and also, it&amp;#x27;s kinda easier to write client libraries for, because it&amp;#x27;s so much simpler (although the parallel and concurrent nature of connections will challenge a lot of programmers).&lt;p&gt;It&amp;#x27;s not bad to see a new contender in this space, but it&amp;#x27;s surprising that it isn&amp;#x27;t http&amp;#x2F;2 first. Is there a good reason for this? It&amp;#x27;s busted through 90% support on caniuse, so it&amp;#x27;s hard to make an argument that adoption holds it back.</text></item></parent_chain><comment><author>stock_toaster</author><text>One possibility is that HTTP&amp;#x2F;2 is much more work to implement, and since it isn’t &amp;#x2F;absolutely&amp;#x2F; required for base “serve a thing” functionality, it maybe be left to be implemented later.</text></comment>