Replying to @stilkov
It is an advantage over having to build a fully native app for lightweight native function. The customer advantage is not needing to go via the app store.
1
2
No need to convince me of the benefits over native apps. I’m more concerned about the advantages over a plain web app
1
3
By definition a PWA is a web app that uses a Service Worker and has a manifest.json file. These allow it to work offline and to be installed to the user's mobile device or desktop. Pretty strong benefits imho.
1
3
It’s not that I don’t know what it is. It’s that I wonder why these benefits are so relevant. What are good examples of web apps where this is important?
1
Any web app! It’s not so much about using it when offline, but about that when users are on a bad connection they still get a good experience because everything is cached locally and network calls are not needed. Then your app can still be fast and responsive.
1
But what are the useful things it can do if it’s not connected? Surely those are very rare? Twitter as an example – what’s the point of it when used offline?
2
None. But again, it’s about the fact that your app can still function on a slow/bad/flaky connection. That’s the point. You could still use the app then because all assets are cached locally and the app would still be fast and responsive.
1
1
Disagree. You could queue retweets for when you are reconnected. You could batch fetch your timeline and have it still there as you click back and forth.
1
Same with my banking app. My historical data can be local and available even if current transactions aren't. Don't think like someone in a major city in the 5g era. Think how it would work with lower bandwidth or intermittent connection.
1
If all you care about in your customer base is highly connected people in major cities that aren't experiencing technical or social interruption, then you don't care. There is no need for PWA Uber.
1
I don’t really buy that argument. If you really care about users with bad connections and shitty devices, using SSR and as little JS as possible (and progressive enhancement when your do) seem to me the key aspects, not the offline/service worker part

Oct 23, 2020 · 4:55 AM UTC

1
1
A Service Worker requires little JS and can eliminate most network calls, whereas with SSR you would still need to fetch more than necessary. But one doesn't need to rule out the other. You can have good SSR for first render and let the Service Worker take over after that.
2