But how is that a problem of SPAs in general? This sounds more like a problem of using Firebase for prototyping.
* How do you allow users to continue using your SPA without a network connection?
* How do you enable snappy and responsive UIs when the network is slow?
* How do you synchronize state between client/server?
These are just some of the "hard problems" that you'll face building an SPA. Firebase has its own solutions but many other tradeoffs. All I'm saying is that we don't have hardened open source solutions for these problems yet, in the same way that we have Rails/.Net Core MVC/Django for traditional websites.
How do you do this with a traditional web site/app?
> How do you enable snappy and responsive UIs when the network is slow?
How do you do this with a traditional web site/app?
> How do you synchronize state between client/server?
At worst you do it just like a traditional web site/app
True, these are all problems that you deal with when building a single-page app, but the worst case scenario is that you end up with some of the same problems as traditional web sites. None of these are new problems that are introduced by the fact that you're building an SPA.
The new problems that SPAs introduce are things like history/back button breaking and how do you let users bookmark things or share deep links.
In the days of server-rendered apps before SPA was a thing, the answer to all of those questions would've been some version of "You don't," followed by "Why would anyone expect a website to work offline, or be fast when the network is slow?"
But SPAs are in a sort of "uncanny valley" where they sorta look and feel like native apps and users expect them to behave like native apps but doing that is much more work than building a simple webapp.
There's a bit of cargo culting here too, I think. Not everything needs offline support and instant updates from Firebase. But $fancy_native_mobile_app has it, so our imitation SPA must too.
How do I manage state? How do I handle offline and intermittent?
Btw, http://hood.ie is one good option.
localstorage for offline state , if your serviceworker reports the app is offline then any changes of state go into localstorage and are queued for updating when the network is back online.
Any changes to the server side state can be diffed against the localstorage changes and you deal with it according your priorities. i.e is the user always right or does the server take priority?