[Matthias247]

That doesn't necessarily solve the problem which is in focus here. The QUIC version which is available in browsers (ok, Chrome only) is not only the QUIC stream layer, but also the QUIC HTTP adaption layer. From javascript side you just interact with HTTP and use QUIC under the hood. However with HTTP you also get all HTTP semantics (headers, reliability, ordering inside of request/response streams, etc.). What is requested is an additional protocol and API which avoids all the overhead and just allows to send and receive messages with best effort - because games and other realtime applications may prefer to build their own reliability mechanism on top.

The only way to use HTTP/QUIC for packetlike communication might be to send each packet inside a seperate HTTP request. But I guess that will have a super high overhead (lifecycle of a whole stream must be managed for a packet which actually has no lifecycle) and will most likely also not deliever the expected results (afaik HTTP on top of QUIC still has head-of-line blocking for request/stream establishment. Request headers must be received in order).

New javascript APIs which are utilizing QUIC could work. However one would need to explore if QUIC is actually helpful for target applications, since it provides a stream semantic, whereas UDP is purely packet based. QUIC might also introduce similar issues like WebRTC to the server side: It's a complex protocol spanning multiple layers (everything from flow-control to encrytion). Therefore it will be hard to integrate into environments where no QUIC library is available. But that's only a feeling, since I haven't yet reviewed the QUIC specification in detail.