Hacker News new | past | comments | ask | show | jobs | submit login

> > writes locally first and then syncs to remote

> Call me old fashioned, but why would anybody ever think doing it differently was a good idea?

Simplicity. Ignoring the issues of broken conectivity, going straight to the server to write and reading back from it, removes the need for both store/retreive and sync - you only have to think about store/retreive. There are unavoidable sync issues (two users load the same object, edit for a while, then save) that you have to deal with but they can be more simply dealt with because you can assume a small number rather than each user potentially having been offline for days and written a novel over many updates to an overlapping set of documents.

Also historically people just haven't had good offline options and many still don't. If you have to contend with users on more ancient browsers/devices (which many of us unfortunately do) then you have to support online working too so if you want to priorities that needs to come first (it supports all possible users) and offline after (as an improvement for those that have devices to support the tech and storage space your solution needs).

Locking issues, while not easy in an online client/server setup, are simpler than offline-first. And by simpler I mean actually possible to deal with - with offline first you instead have to deal with conflict resolution.




Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: