I’m not an expert but QUIC doesn’t seem like enough of an improvement over TCP to warrant replacing it, especially given that it’s even more complex.

- 0-RTT handshakes are great but there’s still the problem of slow start.

- QUIC’s congestion control mechanism is pretty much the same as TCP’s and doesn’t perform particularly well over e.g. mobile networks.

- Mandatory TLS means it’s going to be a huge PITA if you ever need to run a quic service locally (say, in a container).

- Having it in user space means there’a a good chance we’ll end up with 100s of implementations, all with their own quirks. It’s bad enough trying to optimise for the three big TCP stacks.

Or we'll have new tooling which makes it simple to enable SSL locally.

Dev and prod should be as similar as possible anyway.

I started using mkcert for this. It's trivially easy to use and fixes all the weird quirks of http vs https:

https://blog.filippo.io/mkcert-valid-https-certificates-for-...

https://github.com/FiloSottile/mkcert