If the app needs data it doesn't have, and the network is being slow/unreliable, of course you should indicate that to the user.
This goes for any app, whether browser-based or completely native.
A naively-made app (on any platform) might block the user entirely with some kind of "this app requires Internet connectivity" modal. A better app will allow them to navigate to other pages, view old (only possibly stale) data, and even compose posts/messages to be uploaded once online.
Honestly, it's nontrivial to think of a "website" that wouldn't benefit from offline capabilities at least in some sections thereof.
Then, there's reducing cost of server compute and bandwidth by caching the application shell (not even on cdn, directly on the clients) and only loading compact data from apis, all while benefiting the user as opposed to exploiting them.
I wanted to respond in detail but didn't get the time, so here goes. Yours are all valid points, but they also reflect the state of front-end development -- incredibly complex. The bar seems to be raised a few notches every month, and sometimes all I want to do is sit down and cry. 😂
I can't even begin imagining the complexity of a progressive front-end that has service workers and offline capabilities. 😐
There's all sorts of open source that will really hide the complexity from you. It's a great choice for any pragmatic business need.
Only in a few rare cases outside of being an obsessive perfectionist do you need to get your hands dirty.
Something like Next.js + apollo-client + workbox and you're off to the races.
Very well said!
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.