"Currently the only site I go regularly that are JS SPAs are ...."
Are you sure about that? Well made SPAs don't look like apps. They navigate seamlessly and instantly because they're not redownloading and parsing all their header and footer HTML, re-constructing a brand new DOM, loading and reinterpreting CSS, and bootstrapping a new Javascript runtime on every click.
Look at https://react.dev/learn, click around the documentation pages - do you think that's an SPA or an MPA?
Open up your network tab, and you'll find out what's happening: When you hover over a nav header, it starts preloading a JSON file containing the content for that page. When you click on a navigation link, that content's loaded into the react DOM and some more prefetches of just JSON content for likely next pages are loaded up. Your browser navi is updated, but you are still in the same original page context you started in. It is insanely snappy to interact with.
https://react.dev/learn is so slow on my phone, it takes 1.5s to open the burger menu, and about 1s to jump to a section. (Google pixel 5a). It must be some SPA that loads the whole documentation all at once I presume. A traditional MPA would probably work much better here.
edit: and like the sibling comment noted, the history back button gets messed up.
edit2: I mistakingly wrote nexus 5a instead of pixel 5a
Do you mean the pixel 5a? Just wondering because it would make a big difference if it was nexus 5 from 10 years ago, versus a much more recent pixel 5!
Whichever it is, it should certainly not take 1.5s to open a menu. Especially not on a website, that aims to teach people something about web development.
If I go to react.dev/learn, click on "Escape hatches" in the menu, and scroll all the way to the bottom of the page, the browser Back button no longer works because they've added nine duplicate entries to my history.
If the official React documentation website can't implement SPA page navigation properly, what chance does anyone else have?
Well that bug is clearly idiotic, and makes me feel a fool for thinking react.dev would be a strong example of sane SPA architecture to link to.
The idea is sound, and the basic loading behavior is as I said (not sure what the people who are encountering 1.5 second navigation times are doing), and the existence of an implementation bug doesn't undermine the theoretical soundness of the architecture.... although, as you say, having one on the react docs is embarrassing.
> (not sure what the people who are encountering 1.5 second navigation times are doing)
On CPU-limited devices (and my computer with 4x CPU throttling enabled in devtools), react.dev appears to block the main thread for 500-1000ms while navigating to some of the "Learn React" pages—even if all the data for that page is already cached in memory.
I remember reading all kinds of blog posts about how Concurrent Mode and Time Slicing were gonna magically solve this by breaking up long tasks and prioritizing above-the-fold content so that it would pop into view faster. It would be funny if, in addition to being unable to correctly use the History API, the React team was also unable to use their own framework's performance features.
>The idea is sound, and the basic loading behavior is as I said
Yes, and that is why despite hating the idea from the get go, which was before 2009. I gave it plenty of time to mature. But the truth is, any technology is only as good as the human factor. We aren't perfect, and that is why even basic thing like this we would make mistake.
And this example just proves it even more. And I am ignoring the site's performance which felt really slow for what should be a MPA ( and it is not ).
Then well-made SPAs seem to be exceptionally rare. Somehow that site lags more than opening a new page on HN. You list all the work the browser is doing and yet somehow the SPA is making it do more. I agree it makes no damn sense and yet that is the experience I have of using them.
Yes, and every major MPA framework optimizes this away, the same way that SPA approaches support server side rendering so you don't see a literal blank page before the app downloads.
I think GP is talking about solutions like https://turbo.hotwired.dev/, which just paste server-generated HTML into the page instead of passing JSON into a client-side UI framework.
> During rendering, Turbo Drive replaces the current <body> element outright and merges the contents of the <head> element. The JavaScript window and document objects, and the <html> element, persist from one rendering to the next.
Does SSR make React a MPA? If "MPA" limits us to only frameworks that have to do a full browser navigation for every interaction, it's a pointless discussion - "MPA" frameworks have had these sorts of optimizations for a decade+ (Hotwire is the newest, but there was Turbolinks before that and PJAX before that). Sure, I'll agree that React is a better approach than using the 2005 version of a framework, but that's not useful.
Architecturally, you'll still designing your application as though the user is performing a complete navigation, there's just Javascript present to optimize away some of the issues with that approach.
Are you sure about that? Well made SPAs don't look like apps. They navigate seamlessly and instantly because they're not redownloading and parsing all their header and footer HTML, re-constructing a brand new DOM, loading and reinterpreting CSS, and bootstrapping a new Javascript runtime on every click.
Look at https://react.dev/learn, click around the documentation pages - do you think that's an SPA or an MPA?
Open up your network tab, and you'll find out what's happening: When you hover over a nav header, it starts preloading a JSON file containing the content for that page. When you click on a navigation link, that content's loaded into the react DOM and some more prefetches of just JSON content for likely next pages are loaded up. Your browser navi is updated, but you are still in the same original page context you started in. It is insanely snappy to interact with.