Single page app across multiple domains

It’d be neat if I could have a single page app that could run across domains.

For example, suppose I had https://foo.gg website about some game tool, then https://foo.blog for the blog. It’d be awesome to be able to switch between content of both domains as a single page app.

Browsers would need some way to be able to determine that the domains are owned by one party, maybe through the certificates or something. Maybe if the SSL certificates are from the same, then it can work?

Suppose there is https://foo.tv for videos, https://foo.ai for some techy stuff, etc, but it’s all different pages for a “website”.

It’d be super sweet to be able to do this without a full refresh, with dynamic routes (f.e. imagine a WebGL app with routes across multiple domains).

From what I understand, CORS enables you to load content from a different domain freely. Since you own both domains, setting up the headers for this shouldn’t be an issue.

And I will be able to switch domains in the address bar using client-side routing, without a refresh?

You wrote

It’d be awesome to be able to switch between content of both domains as a single page app.

so I assumed it’s about the content, but it seems that what you’re really interested in is the address bar.

Hm, I’m not sure how this could work. How can foo.gg and foo.blog be one page? Each domain serves its own page, so there will always be two pages. If the user navigates from one domain to the other, does the new page replace the old page, or does the old page continue to operate for the new domain?

Portals would allow for this to be mostly seamless.

The old page continues to operate for the new domain, with client-side routing. It’d be just like when the /path changes in single-page apps, and the web app can change what the content is doing dynamically, with no refresh. That’s what I’d like to do, but instead of the address bar showing a new path it may show a new domain, without interrupting any animations that are happening in the web app. The same JavaScript context would still be in play, the same DOM, etc.

What would I google to find more info?

See https://groups.google.com/a/chromium.org/d/msg/blink-dev/SgsbpO08AeI/ZyDL6r5FBgAJ

That seems hacky.

It’d be super cool to have a single app, with client side routing across domains. Basically, treating foo.blog and goo.tv as if they were foo.com/blog and foo.com/tv, and letting my app do whatever it wants with it’s DOM.

In this scenario, loading foo.tv or foo.blog would send an equivalent initial payload containing the app code, then client side routing would take over and show content as appropriate based on the current route (just like regular SPAs). In fact, hitting either foo.tv or foo.blog would hit the same server, same IP address, same endpoints. It’s just treating .tv/whatever and .blog/whatever as paths.

With the new gTLDs, this could be an interesting feature. It would also make it easy to make SPAs on subdomains, f.e. tv.foo.com and blog.foo.com in the same SPA, one DOM, one window context.

Note that the subdomain scenario is different: tv.foo.com and blog.foo.com are same site since they have the same registrable domain (foo.com).

It still requires a full page refresh to switch between websites on sub domains though right?

It definitely would be cool for browsers letting us switch subdomains with the History API without refresh.