Why haven't local-first apps become popular?

I don't really get "local apps with sync". Sync to what, each other? In most cases there needs to be an always-on central authority (where backup also happens). My point is that "some device sitting alone in a corner with software and data stored on it" model is outdated (this is the "problem", I hope the "why" is obvious). But "local" should live on, just in the form of users owning most of their infrastructure.

Any time looking at the RO data directly triggers a need to edit it. Eg, you notice a typo or a mistake, you get the idea for a follow up or clarification, etc.

This is not a systems issue this is a UI issue, the state status needs to be communicated to the user. It is ridiculous to retrofit locally first to a app that pretends to the user that it is always online.

Social media could allow you to make posts as a "draft" and automatically send it when you have a connection think of a email outbox. Or even give you a notification if after syncing with the master and it turns out the comment you replied to changed.

If you look at the web a lot of older (fundamental)protocols and applications have local-first build in. Often the design requirements required communication over a connection that is not as available. A few I can think of of HTTP, EMAIL, FINGER, GOPHER, FIDONET, NEWGROUP and more. A shared state is managed for a lot of different domains (code, gaming, chat, message boards) so I feel like it is already quite a solved problem, but there is no one size fits all solution. IMHO that's the sane thing to do for a networked application as you can never grantee that either party is available, and you want to still serve your user the best you can.

It can also have huge benefits for the data provider, especially at scale. - You can lower your bandwidth required drastically. - You can keep a consistent state for your user. - If you are evil you can send a lot more telemetry data or valuable (harvested) data instead.

the LWW is only really useful if you have a value where you can discard the previous updates for the latest, it's a bit like using UDP instead of TCP for communicating your position in a multiplayer game. Or if you don't mind forcing your user to resubmit.

Who did what when why? Everyone has understanding of those semantics.

It's literally entirely on a computer. If that somehow makes it harder to answer basic human questions about the complex things we're using it for, well that means we've got a problem folks.

The problem is with comprehensibility, and it's entrenched (because the only way for a piece of software to outlive its 50 incompatible analogs and reach mass recognition is to become entrenched; not to represent its domain perfectly)

The issue lies in how the tools that we've currently converged on (e.g. Git) represent the semantics of our activity: what information is retained at what granularity determines what workflows are required of the user; and thence what operations the user comes to expect to be "easy" or "hard", "complex" or "simple". (Every interactive program is a teaching aid of itself, like how when you grok a system you can whip together a poor copy of it in a couple hours out of shit and sticks)

Consider Git's second cousin the CRDT, where "merges" are just a few tokens long, so they happen automatically all the time with good results. Helped in application context by how a "shared editor" interface is considerably more interactive than the "manually versioned folder" approach of Git. There's shared backspace.

Git was designed for emailing patches over dialup, there it obviously pays to be precise; and it's also awesome at enabling endless bikeshedding on projects far less essential than the kernel, thanks to the proprietary extension that are Pull Requests.

Probably nobody has any real incentive to pull off anything better, if the value proposition of the existing solution starts with "it has come to be expected". But it's not right to say it's inherently hard, some of us have just become used to making it needlessly hard on ourselves, and that's whose breakfast the bots are now eating (shoo, bots! scram)

I can browse my private my-site.html perfectly without ever having a network adapter in my device. Now granted some modern webapps (chatgpt) are not designed to operate locally, but there are plenty of webapps that work fine from local storage.

A browser is (in my definition) a tool to display what you call a websites, usually a collection of html/css/js resources. One of the options is to retrieve the resources through the network, if you want the latest news for instance. But it is not required and that makes it local-first in my view. I don't think local first means the app can not connect or sync with a remote server.

In the same way as saying we live on earth doesn't mean we are not in space, earth is in space and we are on earth. It is not mutually exclusive.