@slightlyoff Frankly I'm skeptical of _all_ claims of SPA superiority:

- Paying for slow initial load is amortized across subsequent soft navs
- Soft navs are faster than hard navs
- Any of this is worth breaking the back button

You can always point to one SPA where it works, but in aggregate it doesn't seem to be working.

@tomayac @nolan I can't demonstrate it but I used to work on an internal tool that worked very well as a SPA. Every user was on a fast PC with a fast connection, so initial load times were almost instant (and the time to load the working dataset an order of magnitude higher), and we saved a lot of developer resources that way.

Now I can't point out one that's generally available and meant to be used on mobile phones. I don't think it's commercially viable to build that.

@eseilt @tomayac @nolan I work in edtech and our users, students and teachers, click through a lot of content and assessments and exam pages in a single session.

HOWEVER, what we currently have leaves a lot to be desired.

One specific issue is bundles being bigger initial load time is naturally slow. Now think about a class room full of students trying to load that up at the same time. It's very easy to bottleneck even a modest connection.

"But we have a service worker that caches it", except because of our amazing* developer practices we are doing several releases a day which invalidates the clients caches...

@xssfox @tomayac @nolan yeah, caching of app bundles is definitely not a thing in 2025. You only get that for stale apps that don't see active development.

But to be fair, the same is true for SPAs - "it's in the cache" is an argument from the days when development happened slower and unencrypted HTTP was in use.

I'm not saying SPA is a great idea for all internal use cases, for sure. Just that it can sometimes work out.