Live data from Hacker News

Why haven't local-first apps become popular?

marcobambini.substack.com

381–390 of 494 posts

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

#381
post #355

Earlier quoted context omitted.

I’ve never really thought about this - how does Outlook handle this? Has anyone received a “sorry, that room you reserved actually wasn’t available; talk to this other dude who reserved it too” message after reserving a meeting room? Or does it just double book the room? Or is there a global lock on any transaction affecting a meeting room, so only one goes through? (Feels like it doesn’t scale)

Exchange server accepts or rejects meeting requests. There's no offline room reservation so it's pretty simple.

Presumably exchange server is not a single node?

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

#382

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.

We're living in the world of Dubai chocolate and labubu so this tells you everything you need to know about consumer behavior.

Labubu obsession is a surefire sign of economic depression: https://www.youtube.com/watch?v=l1O6bN2zWSM

The really crazy thing is that everyone just forgot a couple of years ago "Dubai chocolate" meant something a lot more gross.

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

#383
post #355

Earlier quoted context omitted.

Exchange server accepts or rejects meeting requests. There's no offline room reservation so it's pretty simple.

Presumably exchange server is not a single node?

Then it does whatever is needed to make it safe. For example, it might use a hash ring to assign each meeting room to a single node, and that node processes one request at a time. Most distributed systems are like this.

A traditional database funnels all your data changes down to one leader node which then accepts or rejects them, and (if A+C in the case of single node failure is desired) makes sure the data is replicated to follower nodes before accepting.

A distributed database is similar but different pieces of data can be on different leaders and different follower sets.

This comment was rate-limited.

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

#384

Earlier quoted context omitted.

I can't imagine wanting to self-host something like Jira, GitHub, or some wiki product unless there's a very big financial cost difference that more than offsets my time and hardware investment. Otherwise it seems like I'm just spending time and effort achieving the exact same result.

Good luck finding vendor that supports isolation of tenants with sensitive data.

I'm not going to spend time trying to fix problems I don't have.

Obviously if your constraints are different, do what works for you.

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

#385

Earlier quoted context omitted.

> Difference from CRDTs The author has made a CRDT. He denies that his algorithm constitutes a CRDT. It's a straightforward merge, not a "fancy algorithm". What specific aspect of a CRDT does this solution not satisfy? The C? The R? The D? The T?

I was going to say that that's not a CRDT because it requires a centralized server (the conflict resolution is "order in which the server received the messages", and clients aren't allowed to share updates with each other, they can only get updates from the server). But now I'm looking at definitions of CRDTs and it's not clear to me whether this is supposed to count or not. Still, every algorithm that's actually lab…

The C in CRDT means the order doesn't matter, which means you can just put all the gossiped changes into a big bag of changes and if everyone knows the same changes, they have the same final document, so a simple gossip protocol that just shares unshared data blobs will eventually synchronize the document. If order matters, it's not a CRDT. This one isn't a CRDT because the order matters if two clients insert text at the same position.

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

#386

Earlier quoted context omitted.

We're living in the world of Dubai chocolate and labubu so this tells you everything you need to know about consumer behavior.

Fads and trends have always existed. Literally as long as we've had culture. What point are you trying to make?

If I had to guess, I would say the GP wants to express that the mass of consumers acts in uninformed silly ways, and with such people local-first has a very low adoption rate, because they usually don't spend a thought about their digital foot/fingerprint or who really owns their data or how they do their personal computing and whether they are independent of anyone else in their personal computing. That there is this huge part of our society, that again and again creates incentives for enshittification.

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

#388
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/UX design.

This makes local-first behave more like Git: clients work offline, push their “commits,” and the server decides the truth. Most of the complexity disappears if the data model is designed with collaboration and ownership in mind.

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

#389
post #5

The author’s journey is probably just starting. I had this exact mindset about 10 years ago. Long story short: distributed systems are hard. A linear log of changes is an absolute lie, but it is a lie easy to believe in.

> distributed systems are hard

Everything is hard if you don't know how to do it.

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

#390
I think developers overestimate how much everyday users care about local-first, or working offline.

At home and in the office, we have the Internet, so it's only on the move in places where you phone doesn't work where this matters and most of us probably don't work in those places enough for it to matter.

I worked on an app a while back, a synchronising drawing app, and ran into the issues mentioned in the article that synchronising is hard and is solving a problem very few people actually have, the need to work offline.

I'm a sort of "desktop app believer" in that I think you tend to get a better UX from native desktop apps than the web, but convincing enough people to believe you or give you money for it is another matter.

Post reply on HN