HTTP/3 is everywhere but nowhere

1. quic

   1 5 191 9.5 C

   In-kernel QUIC implementation with Userspace handshake (by lxin)

   

   Perhaps, but:

   There's ongoing work exploring QUIC-in-kernel-space at https://github.com/lxin/quic, and more generally HTTP/3 will be increasingly optimized over time as it moves towards becoming the majority of HTTP traffic (a few years off, but looks likely eventually). There's no fundamental reason I'm aware of that HTTP/3 would be _inevitably_ slower than HTTP/2, it seems likely for now that it's largely implementation details.

   There's plenty of internet-facing cases with average-at-best connectivity where HTTP/3 would be beneficial today, and isn't available (non-megacorp Android apps, CLI tools, IoT, desktop apps, etc). Even on the backend, it's very common to have connections between datacenters with significant latency (e.g. distributed CDN to central application server/database).

2. CodeRabbit

   coderabbit.ai featured

   CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.

   

3. go

   2 2,252 127,227 10.0 Go

   The Go programming language

   

   and http3 is being implemented https://github.com/golang/go/issues/70914

   Since Go has strong backwards compatibility guarantees, they're unlikely to commit to APIs that may need to change in the standard library.

4. Niquests

   3 9 1,235 9.4 Python

   “Safest, Fastest, Easiest, and Most advanced” Python HTTP Client. Production Ready! Drop-in replacement for Requests. HTTP/1.1, HTTP/2, and HTTP/3 supported. With WebSocket, and SSE! Be free of Requests bondage now.

   

   I’ve been using niquests with Python. It supports HTTP/3 and a bunch of other goodies. The Python ecosystem has been kind of stuck on the requests package due to inertia, but that library is basically dead now. I’d encourage Python developers to give niquests a try. You can use it as a drop-in replacement for requests then switch to the better async API when you need to.

   https://niquests.readthedocs.io/en/latest/

5. OpenSSL

   4 168 27,189 9.9 C

   TLS/SSL and crypto library

   

   Slow adoption of QUIC is the result of OpenSSL refusing to expose the primitives needed by QUIC implementations that already existed in the wild. Instead, they decided to build their own NIH QUIC stack, which after all these years is still not complete.

   They recently caved in, and OpenSSL 3.5 will finally provide an API for third party QUIC stacks: https://github.com/openssl/openssl/pull/26683

   Naturally, it works differently than all the other existing implementations, as it's push-based instead of pull-based. It remains to be seen what it means for the ecosystem.

6. node

   5 1,194 110,653 10.0 JavaScript

   Node.js JavaScript runtime ✨🐢🚀✨

   

   There's some cool stuff & capabilities here. Its surprising to me that uptake has been so slow.

   Node.js just posted an update on the state of QUIC, which underlies http3 & has had some work over the years. They're struggling

   https://github.com/nodejs/node/issues/57281

7. isdotnetopen

   6 1 28 - HTML

   

   These are handful of handpicked twitter posts that are almost 3 years old, including the page itself.

   https://github.com/ghuntley/isdotnetopen

   The website doesn't even explain what they mean by open.

   Nor they explain why they think .NET is not open source.

8. netty-incubator-codec-http3

   7 1 177 6.4 Java

   Experimental HTTP3 codec on top of QUIC

   

   No need to be sad about that list. Java is also missing. There must be millions of enterprise programmers in the world using Java.

   I just checked the Java class HttpClient (a common JDK11+ HTTP client). It currently does not support HTTP/3, so add one more to the list!

   Ref: https://docs.oracle.com/en/java/javase/24/docs/api/java.net....

   Also, most of the very best network clients are now built on top of NettyIO. I can see an "incubator codec" here: https://github.com/netty/netty-incubator-codec-http3

   Holy hell, this code is ridiculously complex: https://github.com/netty/netty-incubator-codec-http3/tree/ma...

   I'm not hating on NettyIO here, but the protocol looks complex. Yet another reason why it is so slow to be deployed to more application frameworks.

9. InfluxDB

   influxdata.com featured

   InfluxDB high-performance time series database. Collect, organize, and act on massive volumes of high-resolution data to power real-time intelligent systems.

   

10. source-build

    8 11 271 6.7 Shell

    A repository to track efforts to produce a source tarball of the .NET Core SDK and all its components

    

    Because in the relevant distros it is included in the first-party feeds. Only Debian acts like a special snowflake making it needlessly complex for everyone (including Rust). I believe there is an ongoing conversation to contort .NET's full source build (i.e. https://github.com/dotnet/source-build) to satisfy Debian's admission requirements, but really it's a problem inflicted by Debian on themselves, not the other way around.

11. coderev

    9 4 143 8.6 Vue

    CodeRev is a lightweight tool that helps teams conduct technical interviews using code reviews.

    

    We are in a thread about...backend application servers.

    Most of my side projects are TS/JS and run serverless Node.js functions on the BE[1]. I don't choose favorites; I choose the right one for the job.

    [0] https://typescript-is-like-csharp.chrlschn.dev/pages/intro-a...

    [1] https://github.com/CharlieDigital/coderev

Suggest a related project