For a SaaS style (aka client-server) application, the right way to think of client-side storage is as a persistent cache, for a few reasons:

* it can be deleted at anytime (by browser, or even by user!)

* you generally want the server to be authoritative. if there's a bug client-side, server view of state should win.

* it's not possible in the general case to store all user data offline, it's always a subset.

Once you realize that the client-side state is a cache, potential uses of it become a lot more clear.

That's the thing. I want to make apps where the client-state is more than a cache. I want it to be able to be authoritative.

Sure, you probably want to put some sort of syncing on top, but that isn't even always necessary.

Alright, there is some naming collision then.

"offline-first" (terrible name, but here we are) generally refers to a classic web application that wants to be able to run offline either for network resiliency reasons or for performance.

"local-first" is a term that has been coined for something close to what you are talking about: https://www.inkandswitch.com/local-first.html

You can do that with CouchDB installed on the client's PC. Syncing that with a Cloud based CouchDB is trivial, and fast and efficient, and requires no user interaction.

The most important thing to do is get your users data somewhere safe as quickly as possible. For the vast majority of users that means your cloud database.

As the user generates new data, spray it to your servers as well as writing it to the syncable IndexedDB local storage, and to an in-memory buffer. Make your backend handle writes idempotently, and retry all failures a few times. (Eg, IndexedDB disk might be full or flaking out, so retry writing the memory buffer to disk.)

As long as the write path is quick, users can tolerate the browser nuking offline storage cache because they can re-download all the data that made it up to your server.

Hopefully soon the browser vendors will allow more durable file system access with appropriate user controls. Chromium built out the file system access API (https://web.dev/file-system-access/) but it’s not supported in Firefox or Safari.

Is this (generally) reliable?

I know terrible, awful bugs eventually doomed WebSQL from getting any traction and IndexedDB seems to be a more competent replacement, but the fact that Google is leaning on FSA seems like a non-starter.

It just feels like there's no way in hell Webkit will ever implement this stuff - not because of the divide between the App Store and PWA's - but due to the implications for privacy.

Hard pass.

I’m not sure exactly what your reliability question is about. I haven’t actually used the file system API I posted, probably same as you I’m waiting for it to ship outside of Chromium.

On the subject of WebKit, IndexedDB bugs are also pretty bad especially on iOS; we have debated about turning off IndexedDB write buffering in Safari and just do in-memory there. The best thing to do on Apple platforms is to make the app they’re trying to force you to make. Then you can make a little adapter so your web app can write to disk using SQLite and enjoy a nice relational API without needing to worry about the whims of the browser.

From the people who have used it, does it do what it says on the tin?

If it's the only real option and it's half baked (performance-wise), fine, but I'd be really concerned if the replacement for buggy code didn't actually do what was promised.

On the plus side, SQLite seems to be pretty stable on iOS, so at least there's a chance of it working out.