Live data from Hacker News

Why haven't local-first apps become popular?

marcobambini.substack.com

251–260 of 494 posts

Re: Why haven't local-first apps become popular?

#251
The article is about syncing an app that runs locally with other instances of the same app on other machines. Ok. What does that have to do with the title?

> Why haven't local-first apps become popular? (

I think that the title wants to be is "Why haven't more developers written local-first apps for their syncing solution?" because the the answer to title itself is because users don't care. Users (most) want apps that sync between their phone, their tablet, and their laptop/desktop. Up to some point, they don't care how it happens, just that it does and that they don't have to give it a second thought.

Re: Why haven't local-first apps become popular?

#252

Lotus Notes and later Groove Networks (both brought to us courtesy Ray Ozzie) both provided a platform to create apps with data synchronizing as a first-class citizen. The technology behind Groove now powers OneDrive and Microsoft 365. Notes: https://en.wikipedia.org/wiki/HCL_Notes Groove: https://en.wikipedia.org/wiki/Groove_Networks

I was a developer on both Lotus Notes and Groove, and I think both died for different reasons.

Notes was replaced by the web (and Outlook). Notes was, IMHO, ahead of its time. It was one of the first client-server systems where the client was treated as a full peer in the network. You could work offline for as long as you wanted and then the client would automatically synchronize with the server. It had military-grade encryption, a built-in development environment, integrated full-text search, and programmable agents for scheduled data processing, alerting, etc.

But the web was much cheaper and benefited from network scaling laws (the more sites, the more value it accrued). The web is a perfect example of "worse is better". The complexity of Lotus Notes kept the price high (both financially and in terms of time-commitment).

For Groove we doubled-down on peer-to-peer synchronization. Notes had synchronization at the "note" level. If two people edited the same note while offline then there were conflicts that had to be resolved manually. In contrast, Groove had custom synchronization systems for different kinds of data. For text files we could synchronize at the character level. Other data structures could synchronize at whatever level was appropriate.

We used a change-log merge system, not too different from block chain.

The problem with Groove was that the advantages (offline editing) never compensated for the disadvantages (lower performance, lack of visibility in sync state, and difficulty in onboarding).

The use cases that really needed Groove were rare, and not enough to build a viable business.

Re: Why haven't local-first apps become popular?

#253

> One of the simplest CRDT strategies is Last-Write-Wins (LWW): > Each update gets a timestamp (physical or logical). > When two devices write to the same field, the update with the latest timestamp wins. Please also have a robust synced undo feature , so it's easy to undo the thing you don't want that gets written. Apps that sync often seem to be stingy about how much "undos" they store/sync (if any).

Editing on phone. Phone dies. Scrounge up tablet, edit again, only rethink some of the work. Hit save. Plug in cellphone. Cellphone turns on. Now what?

Depends on the granularity of updates. Did the last changes get sent immediately? Are they gated by a save button? Are they periodically pushed?

Some of those don’t need a durable undo, but the rest definitely benefit, and undo has other uses.

Re: Why haven't local-first apps become popular?

#254

I'm not sure CRDTs are actually the right answer here for your example of #2, Marco. A double-entry accounting system might actually be more ideal. In that case, what you are keeping in sync is the ledger, but depending on your use-case, that might actually be easier since you can treat them as a stream-of-data, and you would get the 'correct' answer of 100. In this case, you would need two accounts, a credit and deb…

That's not what a double-entry accounting system is for. If all you're doing is keeping track of one account/balance, then double-entry doesn't add anything. You might want to still implement it that way for future proofing though if you're implementing an accounting system.

The main thing to takeway is to store transactions like you mentioned (+20, -20). And in the simplest case, just apply all of them based on time.

Re: Why haven't local-first apps become popular?

#255
There is increasing awareness of CRDTs but it’s still unclear to many developers how to integrate them with sql. It seems like a CRDT requires developing a new app, or at least a new data model, rather than benefitting from their existing knowledge.

This should change over time; the libraries and documentation keep getting better.

I recommend Automerge 3.0’s documentation as an introduction to the concepts and how to bridge with traditional data. https://automerge.org/docs/hello/

Re: Why haven't local-first apps become popular?

#256
post #203

Earlier quoted context omitted.

It's crazy that we live in a time when "pay with money and your data" or "pay with your eyeballs" are the only viable options and "pay with your money without your data" can't even be considered.

The problem with local apps is actually a problem with closed-source software. I refuse to rely on closed-source software to access my data because then I am beholden to the vendor of that software to access my data. It’s only slightly better than putting my data in the cloud. What I really want is the source code to that local app so I can guarantee the ability to continue accessing my data forever. This can be done…

Would you feel the same way about a closed source local-first app that used sqlite as the underlying database?

That would let you access your data forever, albeit you might still need to write your own scripts to port it to another app.

Re: Why haven't local-first apps become popular?

#257
post #203

Earlier quoted context omitted.

It's crazy that we live in a time when "pay with money and your data" or "pay with your eyeballs" are the only viable options and "pay with your money without your data" can't even be considered.

The problem with local apps is actually a problem with closed-source software. I refuse to rely on closed-source software to access my data because then I am beholden to the vendor of that software to access my data. It’s only slightly better than putting my data in the cloud. What I really want is the source code to that local app so I can guarantee the ability to continue accessing my data forever. This can be done…

wouldn't it be enough for the underlying user data to be stored in a well-documented and widely supported format? I don't care if Obsidian, Logseq or similar are open or closed source if my data is just a folder of markdown and jpeg/pngs.

Re: Why haven't local-first apps become popular?

#258

The free software evangelist in me says "because local-first gives more to the user of the software," which will tend not to happen when the user is not in control of the software. Realistically the reason is probably that it's easier to make changes if you assume everything is phoning home to the mother ship for everything. Also, an unrelated nit: "Why Local-First Apps Haven’t Become Popular?" is not a question. "Wh…

Apple is practically the most antithetical to "free software" company around, yet Apple maintains perhaps the largest fleet of local-first apps in existence, e.g., off the top of my head: Calendar, Contacts, Keynote, Mail, Notes, Numbers, Photos, and Pages (these are all examples of apps that support multi-device sync and/or real-time collaboration). I think the truth of your statement is more that free software tend…

The Windows desktop version of Microsoft's suite is probably bigger, more widely used, and just as local-first than Apple's suite, with the exception of the new version of Outlook that's still very far from replacing the traditional and local-first version. (They haven't tried to do any such replacement of the rest of their suite.)

Re: Why haven't local-first apps become popular?

#259

Earlier quoted context omitted.

Today you can still buy Microsoft Office as a one time purchase.

But it still prompts you to sign into your account and "finish setting up Windows" by using onedrive and whatever other cloud bullshit. And it will continue to do that forever. Source: when we lose power and the machine restarts unexpectedly, I die a little inside when it goes to the windows set up screen just because I haven't signed in to a Microsoft account.

Do you care about not having a subscription? If so that solves that problem. But in 2025, I have three devices where I for whatever reason may want to have access to my document - my phone, tablet and personal MacBook. That’s not even counting in a pinch, editing on the web if I’m at another trusted computer or on my work computer.

Re: Why haven't local-first apps become popular?

#260
post #249

Because when your selling point is that its local first (or distributed, or any other politically trendy thing), you concentrate on that over the app's core value proposition. The end result is you make an app that does what people think they want at the expense of doing as good a job as possible at the thing people actually want.

When I switched to Immich, I thought I was going to give up a lot for the sake of self hosting. To my surprise, it’s actually better than anything I’ve used from Apple or Google. Unicorns exist, they are just rare.

> Why haven't local-first apps become popular?

The Immich "Quick Start" step 1 is mkdir and wget commands. Step 2 is "Populate the .env file with custom values"

I get it, when the prerequisites are 1) run a server and 2) have Docker installed, but this isn't inspiring confidence that local-first apps will become popular.

Post reply on HN