Live data from Hacker News

Why haven't local-first apps become popular?

marcobambini.substack.com

361–370 of 494 posts

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

#361

> 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…

There's the additional headaches of a) managing auth in a distributed manner, and b) figuring out how to evolve the data model across all participating clients.

CRDTs are a complicated way to solve a problem that most services don't really have, which is when you want to sync data but don't want to have any one client be the ultimate source of truth.

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

#362
We have been building a local-first browser app (PWA) for personal finance, based on double-entry accounting. https://finbodhi.com/

It's not always offline. We do use online services like firebase for auth and subscription, and some service to fetch commodity prices etc, but rest of the data is stored in browser storage (sqlite) and backed to local disk and dropbox. We also syncs data across devices, always encrypting data in transit. We use Evolu for sync.

For most personal applications, this model seems to fit. If you figure out sync, the development model is actually nicer than web apps. There is no need for dealing with calls over network for each action. It does make some things more difficult. Debugging, migrations etc.

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

#363

The article is wrong. Its not popular because of greed. We used to have offline everything and everything just worked. Now we are forced to sync with the cloud weather we like it or not. A subscription model shows a continuous cash flow and businesses like that.

This is the correct answer. Consumers also don’t seem willing to pay for privacy, sadly, when they can get a product for «free» in exchange for data.

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

#364

> 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…

> Also remember it turns your data model into (...)

I don't this is true at all. A CRDT is not your data model. It is the data structure you use to track and update state. Your data model is a realization of the CRDT at a specific point in time. This means a CRDT instance is owned by a repository/service dedicated to syncing your state, and whenever you want to access anything you query that repository/service to output your data model.

Sometimes problems are hard. Sometimes you create your own problems.

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

#365

> 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…

Almost every time I see CRDTs mentioned it’s used as a magic device that makes conflicts disappear. The details, of course, are not mentioned. Technically an algorithm that lets the last writer win is a CRDT because there is no conflict. Making a true system that automatically merges data while respecting user intent and expectations can be an extremely hard problem for anything complex like text. Another problem is…

> Technically an algorithm that lets the last writer win is a CRDT because there is no conflict.

Your comment shows some ignorance and a complete misunderstanding of the problem domain.

The whole point of CRDTs is that the set o operations supported is designed to ensure that conflict handling is consistent and deterministic across nodes,and the state of all nodes involved automatically converge to the same state.

Last-write-wins strategies offer no such guarantees. Your state diverges uncontrollably and your system will become inconsistent at the first write.

> Making a true system that automatically merges data while respecting user intent and expectations can be an extremely hard problem for anything complex like text.

Again, this shows a complete misunderstanding of the problem domain. CRDTs ensure state converges across nodes, but they absolutely do not reflect "user intent". They just handle merges consistently. User intent is reflected by users applying their changes, which the system then propagates consistently across nodes.

The whole point of CRDTs is state convergence and consistency.

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

#368

Earlier quoted context omitted.

Almost every time I see CRDTs mentioned it’s used as a magic device that makes conflicts disappear. The details, of course, are not mentioned. Technically an algorithm that lets the last writer win is a CRDT because there is no conflict. Making a true system that automatically merges data while respecting user intent and expectations can be an extremely hard problem for anything complex like text. Another problem is…

> Technically an algorithm that lets the last writer win is a CRDT because there is no conflict. Your comment shows some ignorance and a complete misunderstanding of the problem domain. The whole point of CRDTs is that the set o operations supported is designed to ensure that conflict handling is consistent and deterministic across nodes,and the state of all nodes involved automatically converge to the same state. La…

Not the parent comment, but I'll respond.

> Your comment shows some ignorance and a complete misunderstanding of the problem domain.

oof, this is a very strong position to take, and one would assume you have a very convincing follow up to back it up.

And unfortunately I don't think you do. CRDTs can definitely be implemented as a last-write implementaiton. This should be obvious for state-based crdts. The problem is that it's a horrible UX because somebody could type a response to something that's out of date, and then just see it dissapear as they get the most recent message.

Resolving "user intent" by choosing how to structure the problem domain (e.g. storing ids for lines, and having custom merging solutions) so that it reflects what the user is trying to do is the main challenge.

I am quite frankly baffled at how arrongant your tone is given how far off the mark you seem to be. Genuinely makes me think that I am missing something given your confidence, but I don't see what point you're making tbh.

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

#369
It's genuinely too difficult for most developers.

It may sound smug but I spent a lot of time trying to understand how to sync things offline. I'm not saying I am incredibly talented, just that I put in the hard work here.

It's very, very obvious to me that a lot of people in the space just aren't willing to do that. To be frank it's obvious in a few of these posts.

So yeah, it takes a bit of effort. If you don't want to genuinely learn some new shit, dig into the papers, be confused - it's probably not for you.

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

#370
post #331

Earlier quoted context omitted.

How will you know that Bob is typing into it if you're offline?

That's a fair question; we here being under a submission aout local-first apps, and al. Of course, you know the answer: if you're offline, you're not online. Bob gets to type whatever Bob wants, and until you go online, you don't get to overtype anything.

But the offline enabled property allows exactly that.

Both sides type offline and only sync later. Neither would like their change to just be discarded.

Post reply on HN