It's rare to see offline support in a web app for a few reasons:
LocalStorage is easy to use but too limited at 50Mb.
WebSQL got deprecated by FireFox because of secuirty issues years ago ( albeit is still somewhat supported in Chrome ).
The FileSystem API looked promising, and then google killed it.
IndexedDb is the only option, it's slow on writes, therefore requiring major hacks like absurd-sql to be performant.
It's also old, written before ES6, needs lots of boilerplate, but it does actually work.
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...
Even then however there is a limit of 2GB of persistent storage it can use, which is workable but still:
Some versions of Safari are known to delete IndexedDB after 1 week because of power savings.
Chrome does not allow it unless you either accept notifications from that domain and/or pass a certain lighthouse score (these reasons are anectodal and not well-documented).
So yeah it's a mess, and a bit sad considering it will take years to ratify a better standard for this, but not impossible to do.
Also annoying to know that internally your browser is actually using sqlite under-the-hood anyway.
Web based game engines (i.e. XREngine) are able to get by with IndexedDB i think, and apps like https://github.com/actualbudget/actual created by the author of absurd-sql are good codebases to follow as example.
2 GB is a lot when you store plain json document data.
> IndexedDb is the only option, it's slow on writes
Only when you need a new transaction per write. Writing many documents in a single tx is not slow [1]
> Safari are known to delete IndexedDB after 1 week
This is not really a problem because if you have not used the app for one week, you can just replicate the data from the server again.
> WebAssembly based sqlite is coming along nicely too
WebAssembly cannot access the IndexedDB API. In my tests, all the wrappers that use webassembly are slower on writes the just using IndexedDB via javascript.
The fastest you can go is by using a Memory-Synced wrapper around IndexedDB, like LokiJS does it or the RxDB memory plugin. [2]
> This is not really a problem because if you have not used the app for one week, you can just replicate the data from the server again.
You can't if you haven't been able to push up the data for a week.
But in that case, you'd just have to remember to 'use it' ever day or so.
Had a use case a few years back for data collection app in remote African villages. There were definitely situations where a week without decent data access were possible, and 'offline' became a requirement.
"I lost data because I went on a vacation" is not an acceptable failure mode. Users understand "no data is saved" or "all data is saved," complex rules will lead to pain.
I had not looked into RxDB before thank you.
By any chance you know how much their Premium plugin with IndexedDB support costs, their price is not listed.
You could just wrap the web app in Capacitor for mobile and Electron for desktop, and easily use a SQLite db for unlimited persistence. If someone is interested in offline support, I don’t think it is a dealbreaker to have to download an app. That’s pretty common (eg Netflix, Spotify, hbo, any of the streaming services. The offline support only works in the app, not the web player).
Logically it's not a deal breaker (as Electron is quite mature) but practically there are a few problems:
Users are downloading apps less and less and relying more on web links from apps they already have.
So they mostly tend to end up on their browser anyway, and then workflow is disrupted while commuting and going in and out of signal.
Other less important reasons to consider would be in my opinion:
Electron is a bit too heavy on memory for users with 8GB and less of ram albeit it's gotten better lately.
I can't use ublock-origin on chrome or private-relay on safari while using an electron app (in this case however I still benefit from adding a blocklist like https://someonewhocares.org/hosts/ipv6zero/ to my /private/etc/hosts file on mac)
My experience is different regarding Electron apps. Many of the Electron apps I use (Spotify, Slack, Notion) have a web UI option. I never use it and now just a handful of people who sometimes open Notion or Slack on web.
> WebSQL got deprecated by FireFox because of secuirty issues years ago ( albeit is still somewhat supported in Chrome ).
Major technical corrections on this:
WebSQL was never implemented by Firefox. It was an experimental thing that Chrome and Safari shipped, but Firefox refused to because it was the wrong direction since it was certain to in the future cause either major compatibility or functionality problems. The Chrome and Safari developers agreed with this assessment, and so the draft was discontinued, and the two implementations deprecated. Safari finally removed its three years ago, and Chrome has begun the process of removing its this year.
There were no security issues whatsoever—it’s just that what had been made was unsuitable for standardisation, and no one was willing to do the work that would be required to make it suitable for standardisation perhaps because there was no consensus that it would still be a good idea in that form. All up, the WebSQL story is pretty much “it seemed like a good idea at the time because people want the result, and we implemented and shipped it because it was really easy, but then we stepped back and thought things through and realised the entire approach was a mistake”.
> The FileSystem API looked promising, and then google killed it.
The File System Access API [0] exists today. Unfortunately it's only Chrome based browsers, and not Firefox supporting this. Mayby you referred to an older "standard".
Insightful comment! I've faced similar issues when wanting to store an arbitrary amount of data "locally", but usable via a web interface. Because of the various limitations you enumerated, our conclusion was to have a local web server, written in Go, that stores what we need on disk. Then the web application talks over a JSON HTTP API when storing and retrieving.
I think we need to define better (or re-define) what offline support actually means. Even an ideal fantasy implementation of a PM app with offline support will have limitations unless you sync the entire company’s space with all clients (users, files, docs, comments, tasks, roadmaps, etc).
So IMO selling offline support as a feature has to come with a clear description of what it means.
LocalStorage is easy to use but too limited at 50Mb.
WebSQL got deprecated by FireFox because of secuirty issues years ago ( albeit is still somewhat supported in Chrome ).
The FileSystem API looked promising, and then google killed it.
IndexedDb is the only option, it's slow on writes, therefore requiring major hacks like absurd-sql to be performant. It's also old, written before ES6, needs lots of boilerplate, but it does actually work. https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_A...
Even then however there is a limit of 2GB of persistent storage it can use, which is workable but still:
Some versions of Safari are known to delete IndexedDB after 1 week because of power savings. Chrome does not allow it unless you either accept notifications from that domain and/or pass a certain lighthouse score (these reasons are anectodal and not well-documented).
So yeah it's a mess, and a bit sad considering it will take years to ratify a better standard for this, but not impossible to do. Also annoying to know that internally your browser is actually using sqlite under-the-hood anyway.
Web based game engines (i.e. XREngine) are able to get by with IndexedDB i think, and apps like https://github.com/actualbudget/actual created by the author of absurd-sql are good codebases to follow as example.
WebAssembly based sqlite is coming along nicely too. https://sqlite.org/wasm/doc/tip/about.md.
I am personally working on an offline-capable ML product using pyscript, svelte & indexedDb and it's been a painful ammount of fun so far.