Why an offline-first to-do app is faster than a cloud one
Open a typical cloud task app, type something, and press enter. The row appears immediately, because the app is optimistic about the result. Behind it, a request leaves your device, crosses whatever network you happen to be on, waits for a server, and comes back. Most of the time you never notice. On a train, in a lift, or on hotel wifi, you notice a great deal.
An offline-first app inverts that. The write goes to storage on your device and the operation is genuinely complete. There is no request to fail, no spinner to reconcile, and no state where the interface has told you one thing while the truth is still in flight.
Optimistic is not the same as instant
Optimistic updates hide latency; they do not remove it. The app shows the result it expects, then repairs the difference if the server disagrees. That repair is where the awkward moments live: a task that reappears after you completed it, an edit that silently loses to a newer one, a sync error surfaced minutes after the fact.
When the local database is the source of truth, there is nothing to repair. The interface is not predicting an outcome, it is showing one.
What IndexedDB actually costs
Writing a task to IndexedDB is a local transaction measured in single-digit milliseconds. A network round trip to a nearby data centre is tens of milliseconds at best, and hundreds when mobile reception is poor. The gap is not subtle, and it compounds across a session where you capture a dozen things.
Reads matter more than writes for perceived speed. An offline-first app holds the whole working set in memory after one load, so filtering, searching, and switching views never touch the network. Search feels instant because it is running over an array you already have.
Offline stops being a mode
Most apps treat offline as a degraded state, announced with a banner and a warning colour. That framing is backwards for a capture tool. The moments you most need to write something down are often the moments you have no signal.
When local storage is the primary database and a service worker caches the application shell, there is no offline mode to enter. The app opens, accepts input, and works. Reconnecting changes nothing you can see.
The trade you are making
Offline-first is not free. Without a server, there is no synchronisation between devices, no shared lists, and no recovery if the device is lost and you have not exported a backup. Those are real costs and worth naming.
For a personal capture tool the trade is usually worth it. The value is in getting a thought out of your head in under two seconds, and every network dependency works against that. Sync can be added later on top of a local-first data model. It is much harder to go the other way.
Questions
- Is an offline-first app slower to load the first time?
- Only marginally, and only once. The first visit downloads the application shell and caches it with a service worker. Every launch after that reads from the cache and the local database, so it opens without touching the network at all.
- What happens to my data if I clear the browser storage?
- It is deleted, because the browser storage is the database. This is the real cost of having no server. Export a backup file periodically if the data matters, which in DoTo is a single action in Settings.