The broader problem here BTW (in the context of the now very old original post) is that “Single Page App” isn’t just a presentation-layer approach (or a stylistic preference), it’s an architecture. And it’s an architecture that Bubble doesn’t support very well in it’s current form.
There’s no reason it couldn’t be more friendly to single-page app creation, but it would take some changes. Some of these are quite minor. For example, giving programmers some access to what happens in the case of undefined URLs (routing rules). Because Bubble is designed in a specific way, inbound URLs are assumed to refer to some pre-defined page in the app. The classic example is this:
https://myBubbleApp.com/keith
In Bubble this means, “open the page in myBubbleApp.com named ‘keith’.”
But lots of people want this to mean, “See that path? Check and see if there’s a User object with username ‘keith’. If so, display the User profile page for User with username ‘keith’.”
In the first case, if there isn’t a real page named ‘keith’ that we can serve up, we redirect to the 404 page. As a result, we always go 404 in the second case.
In a Single Page App, we desire a facility that’s like the second case. We’d like to put some code at the server level that would let us disambiguate URLs and do something sensible, BEFORE going 404. (Basically, “real” single page apps – by which I mean SPAs built in a framework like React or similar – really only have one endpoint and that endpoint figures out what to do with arbitrary paths and querystrings that come into that endpoint. In Bubble, we have multiple endpoints, but less flexibility in terms of what happens there… and no facility for handling arbitrary endpoint URLs.)
It would be rad if we could set a preference in our Bubble app such that, before going 404, we execute some code to disambiguate the unknown URL and route to known pages. This would make doing /keith as a user profile page trivial and let us do fancy things like send state information to the main endpoint of an SPA page.
This would be a fairly easy feature for Bubble to add, as long as the feature were code based. And therein lies the rub, right?
But Bubble’s not about that. Bubble’s (at some level) about enabling non-web-developers to build things that are kinda-sorta on par with things built by people who understand web development.
So I wouldn’t expect a quick resolution to this issue. (Though, who knows, perhaps Bubble is thinking about this and working on this. It would be a natural thing to do.)
But anyway, back to the broader topic at hand, what Single Page Apps do is manage their internal state locally and are very good at re-establishing their state after something like a page reload.
So it shouldn’t surprise anyone building a “single page app” in Bubble that – duh – they’re going to need to at times save the state and re-establish it. But of course, the people building “single page apps” in Bubble often don’t actually know what it is they are doing and so are surprised when they learn the requirements of what it is they are attempting to do. 
All the above being said: It wouldn’t be that hard to retool Bubble to be more React-like (it’s already remarkable React-like, really), but it poses a completely new set of challenges in terms of how you build the point-and-click interfaces to support no-code development of this type.
But in terms of arbitrary URL processing we actually already have almost everything we need: We have SSAs (which run nodejs code on the server and can return arbitrary text [and other data type] results). All we need is a way to insert an SSA between Bubble’s default routing strategy and the issuance of a 404, and a mechanism (API) for telling Bubble, "Hey, don’t return 404 and go to the 404 page, go here instead.) And… problem solved. (Concerns about spin-up time of SSAs, notwithstanding.)
