[sholladay]

In Node.js (curious to hear about other ecosystems), HTTP/2 hasn't even caught on yet. Sure, it's technically supported by Node core and various frameworks, but hardly anyone is really using it. Most of the benefits that HTTP/2 brings to the table require a new model that doesn't map cleanly to the traditional request/response lifecycle. It seems harder to program applications using HTTP/2 because of that. Perhaps some of it is what we are used to and the burden of learning something new, but I don't think that's the whole story. I wonder if future HTTP versions will address this in some way or if it is going to continue to be the new normal. It will be interesting to see what the adoption curve looks like for HTTP/3 and onward. I'm still building everything on HTTP/1.1 (RFC 7230) and have no plans to change that any time soon, even though I can appreciate the features that are available in the newer versions.

[Androider]

Turns out it's not really an issue in practice, since you rarely serve naked Node.js to the Internet. If you put something like a load balancer (ELB) or reverse proxy (Nginx) in front of your service which speaks HTTP/2, you already get 95% of the benefits. I expect HTTP/3 to likewise just be a toggle offered by AWS/GCP/Azure/NGinx etc. in the future, and your users will see an immediate benefit.

[steveklabnik]

Cloudflare includes such a toggle for HTTP/3, though to be honest I forget if it's still in a closed beta or more generally available.

[Matthias247]

> Most of the benefits that HTTP/2 brings to the table require a new model that doesn't map cleanly to the traditional request/response lifecycle

This is not true. The only HTTP/2 feature that doesn't fit into the traditional HTTP semantics is PUSH. And even that is the request/response model - the only difference is that the request is injected also from the server side and not being received from the client. We just pretend we would have received such a request from the client, send the response towards the client, and hope the client won't reject it.

[labawi]

0-RTT requests mess with the traditional lifecycle and have security implications that many won't handle safely.

[Matthias247]

0-RTT requests certainly have security implications. However they are not part of HTTP/2, but of TLS1.3 (and QUIC). They are orthogonal concerns, even though it's a valid layering concern: We have a transport layer concern leaking up into the HTTP layer - whether it's HTTP/1.1, /2 or /3.

Also 0-RTT requests still follow the request/response model.