ShadowDOM is actually a big part of the reason where the perf comes from because the universe of what actually needs to be considered in order to get to the eventual answer of what style properties should any given element actually have is tiny due to the fact that it is encapsulated.
That and the the other big win comes from using native compiled C++ browser code to implement large chunks of what libraries typically provide in userland JS.
React is probably the worst offender here as it for all intents and purposes brings its own implementation of both DOM and events. It’s just an outdated architecture choice that made a huge amount of sense at the time but nobody would do that today if they were building a front end library from scratch.
Finally regarding your point about the message bus idea you might want to take a look at the BroadcastChannel API if you aren’t already familiar with it. Sounds like it might be what you’re looking for.
One approach I don’t mind is to just make a HTML file per screen in the application and route like the rest of the web.
When you bring in modern things like service workers and the prefetch API you can still very much keep the speed that is traditionally associated with SPAs.
Otherwise I’ve seen good things said about both of these options:
One file per screen is actually awesome. That's the "MPA" many frameworks are boasting about.
The big win here would be that if you have a huge app (let's say an ERP kind of app that has too many screens and dialogs and what not) then that can be easily decomposed into separate pages that are far more manageable.
You can easily wrap these pages up as Electron/Tauri app or Capacitor etc for mobile.
Deep linking however would be interesting in that if someone pastes a URL, we have to load the exact screen/dialog etc.
That and the the other big win comes from using native compiled C++ browser code to implement large chunks of what libraries typically provide in userland JS.
React is probably the worst offender here as it for all intents and purposes brings its own implementation of both DOM and events. It’s just an outdated architecture choice that made a huge amount of sense at the time but nobody would do that today if they were building a front end library from scratch.
Finally regarding your point about the message bus idea you might want to take a look at the BroadcastChannel API if you aren’t already familiar with it. Sounds like it might be what you’re looking for.