Live data from Hacker News

Why haven't local-first apps become popular?

marcobambini.substack.com

461–470 of 494 posts

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

#461
post #371
post #329

Earlier quoted context omitted.

You've made a general argument that shows not all theoretical economic theories about free markets can be trusted. Fair enough. But my claim is much narrower. It merely relies on the love of money of real people in our current economy, and the premise that there is enough information flow that, if people cared, they would find and pay for products that don't screw their privacy, control, etc. I think both those premi…

> and the premise that there is enough information flow that, if people cared, they would That's a terrible premise. Why are you assuming that this flow exists and that billions of people are failing individually rather than the simpler one this flow not existing?

One reason: Whenever I've made the case personally to friends/family, people who are smart but not interested in messing around with tech, I am usually met with a giant shoulder shrug. Or perhaps, in a best case scenario, "Yeah that doesn't sound great, but there's no way I'm installing X to deal with it".

We can always say the case hasn't been made well enough, and maybe it hasn't it, but at what point do you just start believing people?

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

#462
Host of localfirst.fm and author of LiveStore here. Your post strongly resonates and I particularly like your conclusion in regards to SQLite.

I've been exploring how to build a sync layer around SQLite for the last 5 years as part of LiveStore and settled on embracing event sourcing following a similar architecture to Git but for your application data.

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

#463

> The Solution: CRDTs. The right approach is CRDTs (Conflict-Free Replicated Data Types)... This means you can apply messages in any order, even multiple times, and every device will still converge to the same state. This is very much "draw the rest of the owl". Creating a CRDT model for your data that matches intuitive user expectations and obeys consistent business logic is... not for the faint of heart. Also remem…

We have a local-first app. Our approach? Just ignore the conflicts. The last change wins. No, really. In practice for most cases the conflicts are either trivial, or impossible. Trivial conflicts like two people modifying the same note are trivial for users, once you have a simple audit log. And impossible conflicts are impossible to solve automatically anyway and require business processes around them. Example: two…

Who is the audience of your app? Is it an internal app for a company, or is it a public facing consumer app?

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

#464

Earlier quoted context omitted.

Either people are broadly ok with being screwed (my personal experience suggests this) or there is a grand conspiracy to prevent anyone who is not screwing their customers from competing in the market. Maybe it is the latter, who knows. But what I do know is that the non-screwing options exist, but are often less popular and more expensive (either in price, time, or effort). And this annoys me to no end. Because _I_…

It's not that people are OK with being screwed over but rather that they have been conditioned into being helpless about it. Big corporations hire psychological experts that know exactly how to manipulate you into thinking you need their products or otherwise act against your own best interests, whether that's through advertisement, peer pressure or whatever else they can come up with. You yourself admit that while y…

I am partially with you on this one.

"Yes people often technically have options of not getting screwed but those options almost exist in a different world and in order to choose them you have to abandon the one you are living in now."

But the question that remains is this: If the true situation is people who'd desperately like not to be screwed, and would pay the same or more for this privilege, but are made helpless by corporate propaganda and market dominance, why do we not see new players rushing in to fill this need? They could take massive amounts of market share.

There are only two explanations I can see:

1. Monopoly forces or similar at work.

2. This is not the actual situation.

Regarding 1, you can make the argument for a network effect/coldstart problem. That seems possible to me as an alternative explanation, and as a way out. Still, in my personal experience, 90% of people just don't care that much, and so are vulnerable to essentially being "bribed" by short-term corporate incentives. The free/privacy-respecting alternatives would have to match this force, and also match the marketing.

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

#465

CRDTs and HLCs often feel like over-engineering. In most business/management apps, it’s rare for two people to edit the same piece of data at the exact same time. A simpler approach works surprisingly well: Store atomic mutations locally (Redux-like) in SQLite. Sync those mutations to a central server that merges with last-writer-wins. Handle the few conflicts that do occur through clear ownership rules and some UI/U…

Agreed @ overengineering for most use cases.

Still, where a simpler approach gets tricky is if you only want to sync a subset of the backend database to any client's SQLite

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

#466
post #8

I feel like a broken record here: it is not an engineering problem. Local-first and decentralized apps haven't become popular because SaaS has a vastly superior economic model, and more money means more to be invested in both polish (UI/UX) and marketing. All the technical challenges of decentralized or local-first apps are solvable. They are no harder than the technical challenges of doing cloud at scale. If there w…

Epicenter[1] is attempting to go against the grain here[2]. I'm not sure if it will require one of these SaaS to become a client for this business model to work... > The long-term direction is for Epicenter to become a foundational data framework for building apps where users truly own and control their own data. In other words, the Epicenter framework becomes an SSO for AI applications. Users use Epicenter to plug i…

Two things make local‑first frameworks break out: a boring hosted “default” and one killer app. Even if the vision is user‑owned data, ship a managed option with sane defaults so teams can try it in 5 minutes, then let them flip a switch to self‑host or bring their own storage/keys later. Pair that with a flagship app that proves the value (e.g., a shared notes/CRM/mail client where offline + conflict‑free collab is obviously better). Frameworks without a hero use case tend to stall because devs can’t justify the integration time.

On the business model, dual license works if you de‑risk the integration: stable plugin ABI, permissive SDKs, and paid “closed‑source embedding” tier with SLAs and on‑prem support. Where I’ve seen revenue actually land: (1) paid sync/relay with zero data retention, (2) enterprise key management and policy controls, and (3) priority support/migration bundles. One caution: “privacy” alone doesn’t convert; solve a concrete ops pain. I built CrabClear to handle the obscure brokers others miss, and the lesson was the same—privacy sells when it eliminates a specific, recurring headache. If Epicenter can quantify one such headache and make it vanish out‑of‑the‑box, the model becomes much easier to sustain.

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

#467
post #379
post #351

Earlier quoted context omitted.

The details appear to be not giving a damn about changes to data. I personally wouldn't describe that as "converging". As it says, this is "Last Write Wins", which is great if the last writer is always correct. "If it’s older → ignore" -- yea, I guess that's a solution but I would really have to look for the problem. I've gone down this road and considered github (or similar) as the backing database. In the end, I ju…

Funny thing is that the article gives an example where "last write wins" is quite clearly a bad solution. Balance = 100 A: balance = 120 B: balance = 80 Clearly, these are transactions, and it doesn't matter in which order they're applied, but it does matter that they're both executed. End balance should be 100, not 80 or 120.

I was thinking about this overnight and maybe my beef is the article feels like it's written as a solution to "offline", when really it's a much narrower solution.

This solution doesn't nearly move us toward making local-first apps more popular, which was nominally the theme.

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

#469

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…

You're not entirely wrong that double-entry accounting doesn't add much to keeping track of one balance. And the example provided in the article was very simple, just like mine was very simple. Transactions do help, but if you are trying to keep track of a balance and understanding how that balance is changing, double-entry accounting is helpful.

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

#470
post #234

They used to be really popular, back in the ancient times when I was young and full of excitement for all things compute, almost all software was local-first, and.. only :) But since the entire world economy has turned to purely optimizing for control and profit, there's just no good reason to not screw people over as much and as often as possible, what'll they do ? Switch to someone who won't ? And who would that be…

I personally have needed to sync something between 3 and 6 devices over the past 5 years on a daily/weekly basis.

I invite you to figure out how to algorithmically figure this out in a general case without needing Git Merge levels of complexity for data structures far more complicated than lines of code. Peer to peer device merging of arbitrary files for n > 2 conflicts.

The answer - the algorithmically simple and correct answer - is to have a central hoster and the devices operate as clients. And if you have a central hoster, you now gave yourself a job as sysadmin with requisite backup/failover/restore with data management responsibility handling the decade+ case. Or I could hire a central cloud company to manage my tiny slice of sysadmin needs and _not_ have a part time job at home just dealing with file management and multifile merges.

All models that are "I have a laptop and a backup hard disk" are _broken_.

Post reply on HN