Native/built-in browser routing and component loading system

There are sooooo many JS frameworks to do single-page applications (SPAs). And a huge portion of what these frameworks provide is the routing system because developers need a way to load pages and their components without reloading the entire the page and DOM state everytime a user clicks around on the website.

But if browsers implement native routing support for SPAs, we can at least begin to standardize a large chunk of building SPAs. Here’s a naive featureset of things that I think could be provided with a natively-supported routing and loading system, much of which are already implemented by current frameworks today.

  1. Global Configuration - to specify app-level settings using the manifest.json file for example. Maybe a new display attribute of single-page-application or something similar which would put the application in “spa mode”

  2. Route configuration - to specify path references to the components to load when certain URLs are requested and any dependencies. This can be a separate file that sits at the root of the application similar to manifest.json or maybe even inside of the manifest file.

  3. Handle in-app page requests - When a user requests a new relative url (by clicking an internal link for example), based on the route config above, the browser would determine whether the url request should be loaded in the current DOM (spa link) or not. And if the former, load the contents in the DOM without a full page reload

  4. Dynamically load requested pages along with any nested components specified in the route configuration above. I also think this would eliminate all the chaos and controversy around importing html modules because, with the right configurations used above, it’s likely they could no longer be necessary.

Obviously this is a very small list of things an SPA routing/loading system could provide and the specifics and implementation details can be changed but I’m curious to get your thoughts on the overall idea.


In the spirit of the extensible web manifesto, it’d probably be best if the standard solution was based on existing libraries for client-side routing that have proven to work well. I personally use the <Router> component in Preact, so I guess a standard <router> element is an option. A “use cases and requirements” spec would help.

1 Like

I like that idea. Previous attempts at providing better high-level abstractions to create the “single page app” model failed to get traction (e.g. Navigation Transitions. Maybe it was because they tried to extend the concept of navigation (so forcing multiple pages to behave like a single page app, which is rather complex) rather than embracing the single page parts, but making them easier (and require less JS).

I think that before diving into the solution, it’ll be great to state the goals and detailed use cases. (as @simevidas mentioned)

/cc @Jake_Archibald

1 Like

I have a feeling that Service Workers will be disrupting a lot around what we used to traditionally think around SPAs. As it is a fully client-side JS router that we can use to intercept requests, even creating entirely fabricated responses which can come asynchronously from other sources.

Perhaps it is also time to disassemble the heart of an SPA, because it might mean that:

  • Why can’t all these windows and tabs be part of the very same application, talking via postMessage & Service Worker, unified to the same database?
  • Would each window simply be a new perspective and view of the same app?
  • Would we be going in the direction to something similar akin to our web version of Electron?
1 Like

@simevidas I managed to create a <router-component> that is a little similar to Preact’s Router. It’s declarative and pretty simple and supports loading webcomponents at specific URLs.

If the goal is seamless navigation transitions, I advice you to check out <portal>.

@Malvoz I did check the explainer. Portals sound awesome but they seem a little different from what I was proposing. Portals make it possible for you to have inset pages that can be loaded from different domains, which just seems like iframes–just a little more seamless. What I meant by my original statement was to make it possible to fully replace areas of the document with new HTML that contains parts can be reused throughout each of the pages. Based on what I read on the explainer, portal insets don’t allow you to reuse the HTML from other insets.