I wonder about the categories of apps for which offline first with potentially infinitely delayed sync provides a better experience and how large those really are.

It seems like most of those are apps where I'm creating or working on something by myself and then sharing it later. The online part is almost the nice-to-have. A lot of other apps are either near-real-time-to-real-time communication where I want sending to succeed or fail pretty much immediately and queueing a message for hours and delivering it later only creates confusion. Or the app is mostly for consuming and interacting with content from elsewhere (be that an endless stream of content a la most "social media", news, video, etc. or be it content like banking apps and things) and I really mostly care about the latest information if the information is really that important at all. The cases in those apps where I interact, I also want immediate confirmation of success or failure because it's really important or not important at all.

What are the cases where offline-first is really essential? Maybe things that update, but referencing older material can be really useful or important (which does get back to messaging and email in particular, but other than something that's designed to be async like email, queueing actions when offline is still just nice-to-have in the best cases).

Otherwise the utility of CRDTs, OT, et al. is mostly collaborative editing tools that still need to be mostly online for the best experience.

> It seems like most of those are apps where I'm creating or working on something by myself and then sharing it later.

It is interesting. I've thought about things I don in non-messaging apps (which are online0first for obvious reasons), and all of them create something, which can be EXPORTED to on-line presence, but doesn't require connected app.

Code? I write it locally and use separate app to share it: git. Yes, code is collaborative creation (I'm working in the team), but it is still separate tool and I like it, as I control what I'll publish for my colleagues.

Photos? Of course I want to share result, but I'm working on RAW files with non-destructive editing and I want to share final bitmap (as JPEG) and not RAW data and editing steps.

Same with music, if I create one (I doesn't).

Texts must be polished in solitude and presented as final result (maybe, as typographically set one, as PDF).

All my "heavy" applications are and should be offline-first!

Yeah, I feel like for most applications the online part acts more like a backup than an interactive sync. How often do you really work on the same file on different devices? And if you do so, how often do you want to continue working on an old version rather than first forcing a sync of the latest revision? After all, without a sync you can't continue your work but only edit completely unrelated parts...

I think most real-world applications fall under either "has to be done online", or "if there are conflicts, keep both files and let the user figure it out". Trying to automatically merge two independent edits can quickly turn into a massive mess, and I really don't want apps to do that automagically for me without giving me git-like tooling to fix the inevitable nightmare.

Apart from small software studios with non-SaaS business models, there is just no viable local-first (offline-first with infinitely delayed sync) application category, in the consumer space. Consider military applications with heterogenous and constraint networks, where assets might need to coordinate p2p under adversarial jamming. There might be applications, where AP (choosing Availability and Partion Tolerance, cf CAP theorem) makes sense.

you are missing one key aspect: high latency. i am in a rural area with bad internet access. especially bad latency. every request to hackernews for example takes seconds. even if it doesn't make sense for hackernews to be offline. updating new messages, posting replies, upvotes, downvotes. etc, would all work better if they happened in the background, so that i don't have to wait for them.

that's why local first also makes sense for server bound applications. it's not offline first, but by moving online activities into the background, all my interaction with the site would be snappy and smooth, and i could read and comment and move on to the next action without waiting for the browser to reload the page