Felt a little lacking some research on options, and manifest configuration is quite a topic on its on, but otherwise an informative post about all the steps required to build an offline app in todays technology.
There are a few options for the frontend such as Angular/React or even webpack with other libraries to help with the offline caching, dealing with or programming service workers is pointless as they don't really provide any other benefit besides caching.
I ended up implementing a syncronization layer myself, which was challenging in a fun way, but I wouldn't use IndexedDB API, it feels much like WebGL interface: overly verbose, stateful, and the specification does not mind web developers at all. For those and other reasons I recommend [Dexie.js](https://dexie.org/) to handle the local DB.
Dexie is great, but it's a good idea to understand the lower level before you start leveraging the wrapper for it. I jumped into Tone.js before understanding the Web Audio API, and I eventually regretted it.
I did a bunch of work to make one of my hobby projects (https://pitchy.ninja) work off-line. The trickiest part was data synchronization between IndexedDB and the database on the server, managing and resolving conflicts if the app was used on multiple devices offline at the same time (then went online again.)
Although IndexedDB worked pretty well in the end, it is a very finicky database, with a really convoluted API. There's a whole bunch of corner cases that you need to handle, and some of these are non-obvious.
Workbox is about service workers. So for very simple stuff like caching assets, it is quite helpful, but I was referring to the more transactional actions like multiple clients writing to the same backend, requiring to resolve conflicts.
It's a single-page-app, so it uses the history API to route between paths. Unfortunately, there's a bug in my implementation (which I haven't been able to nail down yet), which causes the back button not to work consistently on all paths.
Academic project, but from an experienced implementer. Though there are things missing, I suspect for some applications this might be usable already. The "Caveats" section seems like it may be needlessly scary:
> No integrity checking: if a buggy (or malicious) device makes corrupted edits, it can cause the application state on other devices to become corrupted or go out of sync.
I wonder if this can be addressed for now at the application level, on top of automerge?
> No security: there is currently no encryption, authentication, or access control.
This puzzles me: why would a data structure have encryption, authentication, or access control? Perhaps this refers specifically to Automerge.Connection? But I assume any gossip protocol could be substituted fairly straightforwardly?
Otherwise I can only presume that by this he's just saying that the TRVE research program is incomplete -- but as far as I know, almost no software meets that sort of high standard!
Also, it doesn't mention in that section that currently automerge never truncates data. That's a constraint I believe Kleppmann would like to relax in the future.
> I wonder if this can be addressed for now at the application level, on top of automerge?
On reflection, I think the answer to this is very likely "no". I had in mind storing the deltas in a log-structured database -- which I believe is what hypermerge does -- and detecting invalidity at application level and then rolling back to old log records in case of trouble -- but of course that doesn't help with losing sync, or effective loss of data from rolling back or corruption that leaves the data valid, and it's just not very practical.
So, even though I suspect the problems in practice are rare (Martin's clearly a very able programmer), I guess that until he gets around to the integrity work he has in mind, it's limited to apps where the data is very transient for now. Those do exist: say, off the top of my head, a tool for collaborating on sketching simple diagrams -- in fact their pixelpusher demo is quite similar to that idea! I think he's currently focusing on performance improvements.
"it will be easier for you to generate a native mobile-app from your PWA source code using technologies such as Ionic, React Native or Apache Cordova."
I believe react native doesn't belong here, it's not browser powered like ionic and Cordova.
Ionic and Cordova generally are "webview" apps. Essentially a headless mobile web site with access to device APIs.
In modern Android and iOS, you could also just install a PWA directly without wrapping it in Ionic/Cordova with the caveat of losing access to some device level APIs.
React Native utilizes actual native components that are declared via a JS bridge. It's not a webview.
However in the author's defense, with the current work on react-native-web, you could share a lot of your react-native code that would swap device components with their equivalent web based components.
The fact that the younger devs expect this to be a baseline functionality, intuitively, should once and for all solve the age-old discussion about if event sourcing is a good idea or not.
I went a different route. - I installed a LAMP service on my tablet and setup the database to be distributed so I can sync and take the tablet offline.
There are a few options for the frontend such as Angular/React or even webpack with other libraries to help with the offline caching, dealing with or programming service workers is pointless as they don't really provide any other benefit besides caching.
I ended up implementing a syncronization layer myself, which was challenging in a fun way, but I wouldn't use IndexedDB API, it feels much like WebGL interface: overly verbose, stateful, and the specification does not mind web developers at all. For those and other reasons I recommend [Dexie.js](https://dexie.org/) to handle the local DB.