In a better language, this would be the programmers choice on a case-by-case basis, with no need for the higher-ups to break or fix everyone's behaviour at once.
Either return a Page(Future(Components)) or a Future(Page(Components)).
Yes there are cases where React is exactly what's needed but when each new version introduces new "best practices" based on how "bullish" Meta's developers feel about a given approach it removes a crucial advantage that helped these libraries become popular i.e. that it's easy to onboard new people on to a project because thewre's a consistent approach across code bases. Right now there's not a consistent approach across 2 or 3 years of React releases and that's before we come to the torrent of metaframeowrks designed to smooth over inconsitencies and deficiencies (state managment! styling!).
I don't know what the answer to this is but having spent a good portion of the last 7 years or so on and off React projects I would advise anyone to think carefully before investing time and /or money in the ecosystem. On balance the benefits aren't worth it the large majority of cases.
note: i've used library and framework carelessly and interchangably here, React has historically been keen to market itself as a library i.e. something you dip into when needed but in practice it bends the whole dev process around it so I feel framework is more apt
Instead of a choice between progressively loading in /page-a or waiting for /page-a to fully load before showing it, just direct the user to /page-b instead?