My number one solution to any and all CORS issues is to never ever set up an api.* domain. Always do /api on the same domain. If the requests are for third parties, put a proxy on your own hostname if at all possible.
The implicit assumption being that internally everything trusts the proxy?
Proxying requests to a third-party will mean browser security features like CORS will assume they are entirely safe due to them appearing to come from your domain, and not “gist.github.com” etc.
The point is that when you serverside-proxy requests to third parties, you're implicitly trusting the third party to control the DOM for any app in your domain.
They should also use just one domain - DNS lookups are a pretty slow and flaky part of the process of loading a webpage, and downloading loads of HTTPS certificates for all the domains involved isn't great either.
Managing just one domain is also a lot easier - less to monitor, less to maintain, simpler architecture, etc.
The only remaining reason for extra domains is to act as a security boundary - for example when you're running untrusted user javascript.
> Nobody has an excuse not to use either HTTP/2 or QUIC on a modern website.
Sure they do. HTTP/2 is not uniformly superior to HTTP/1.1, primarily due to head-of-line blocking; so that on a poor quality network connection, with multiple HTTP/1.1 connections it’s quite possible that one will come through while another takes longer due to packet loss, while on HTTP/2 it’s all on one TCP connection, so that packet loss affects all requests. That’s what QUIC is about fixing. HTTP/2 is also currently incompatible with WebSockets (there’s a draft in progress for resolving that), so HTTP/2 offers no benefit for WebSocket domains or little-to-no benefit for WebSocket-heavy stuff. HTTP/2 also works differently from HTTP/1.1, so that certain moderately obscure combinations of types of long-lived requests can’t be cleanly terminated in HTTP/2 as they can be in HTTP/1.1 (sorry I’m being vague—I can’t recall the details off-hand). And there’s just the usual “existing software that doesn’t support HTTP/2” justification as well.
(Despite the listed criticisms of HTTP/2, I do agree that almost everyone should be using HTTP/2.)
As for QUIC (Google or IETF variant), it’s still experimental, with various unknowns that are being nutted out, and is not suitable for wide deployment by most entities just yet.
> The only remaining reason for extra domains is to act as a security boundary
No, that’s merely one of the best justifications for additional domains. There are other reasons for using other domains, though I would agree with a less strongly worded version of your initial declaration: that they should try, if convenient, to use just one domain.