Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Of course but if you're writing a web app who's only purpose, for example, is to talk to support staff for your company then having an offline mode is not really useful. If you're offline you can't talk to the staff, so all the app needs to do is fail gracefully. Designing it "offline first" would be silly.

I actually believe that >50% of web apps probably fall into this category, where they really cannot function properly offline because the online-ness s core to their functionality. That's why they are web apps in the first place.

Now if you are designing a web app that is a web version of a more traditional native app like Google Docs or something, then sure offline first makes sense. But I don't think that's the majority of web apps.



Offline first basically means that if you send a message while your network is temporarily down, it's just queued and resent immediately once the link is up again, like your email outbox.

Since network links are always flaky, it just makes sense to do it this way. Since they are also always relatively slow, it makes sense to cache data locally in order to give a faster experience.

Not doing things offline-first in an app basically means that you are introducing synchronous requests everywhere: reading a support reply from yesterday is a synchronous request that fails "gracefully" if your 3G happens to be down, etc.

Telegram's web app is pretty nice. The app code is cached offline with a service worker and updated whenever possible, so it loads instantly. The most recent messages from your contacts are saved in the client as well. I appreciate all that stuff as a user, and the more stuff works offline the better, because it also means it's faster and more reliable.

For more info:

http://alistapart.com/article/offline-first

https://developer.chrome.com/apps/offline_apps




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: