Hacker News Reader

Comment by bloudermilk | Hacker News Reader

Firebase is a solution, not the problem. The problems are:

* 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.

View on HN

> How do you allow users to continue using your SPA without a network connection?

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.

I think user expectations (and/or product/UX expectations) have changed along with the rise of the SPA.

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.

Also, the first rise of the Web was enabled by residential broadband adoption, so that most of your site’s users had a stable internet connection. Now that Mobile devices are the most common, flaky networks are back to being a problem.

serviceworkers for caching content to be available offline (can cache most recent result from an api call so you don't even need to change anything on the frontend)

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?

This is true and these are the things to be asking when planning to develop a SPA.

How do I manage state? How do I handle offline and intermittent?

Btw, http://hood.ie is one good option.

Reply on news.ycombinator.com