Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why haven't local-first apps become popular?

marcobambini.substack.com

Post reply on HN
Print view View original

331–340 of 494 posts

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

#331

Post by avemg »

kazinator wrote: post #312
cyberax wrote: post #303

Earlier quoted context omitted.

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…

One solution is to make it so that people see their literal keystrokes in real time. Then they solve the conflict themselves. Like, "stop typing into this text because bob is typing into it". It's like Ethernet conflict resolution: just access the shared medium and detect collisions in real time.

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

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

#332

Post by tonymet »

m463 wrote: post #296
tonymet wrote: post #284

I wish we could get app developers to stop going online for every piece of content. Even my Tesla GPS map refuses to cache tiles it already has, so when connectivity goes down, my maps are blank. Or streaming media apps (like Peacock & Kanopy) reloading the previous screen from the server instead of keeping the rendered media list object resident. 95% of the content is already on the device, let's please encourage it…

> no major changes to the app design I'm pretty convinced they just want more data. for example, apple allows offline maps, but they expire the data because they want you dependent on them. I'm pretty sure the tesla (google) tile data has hidden motives.

I've also wondered. Having worked on similar apps, I think it's usually due to a bug where data is inconsistent , someone important complains, so the devs just invalidate all data to prevent the bug ever happening again. Inconsistent/stale data is more evident during testing than the caching issues (testers are usually using stable office wifi)

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

#333

Post by kazinator »

avemg wrote: post #331
kazinator wrote: post #312

Earlier quoted context omitted.

One solution is to make it so that people see their literal keystrokes in real time. Then they solve the conflict themselves. Like, "stop typing into this text because bob is typing into it". It's like Ethernet conflict resolution: just access the shared medium and detect collisions in real time.

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.

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

#335

Post by teleforce »

crazygringo wrote: post #273

> 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 is next gen web standards initiative namely BRAID that will make web to be more human and machine friendly with a synchronous web of state [1],[2],[3].

"Braid’s goal is to extend HTTP from a state transfer protocol to a state sync protocol, in order to do away with custom sync protocols and make state across the web more interoperable.

Braid puts the power of operational transforms and CRDTs on the web, improving network performance and enabling natively p2p, collaboratively-editable, local-first web applications." [4]

[1] A Synchronous Web of State:

https://braid.org/meeting-107

[2] Braid: Synchronization for HTTP (88 comments):

https://news.ycombinator.com/item?id=40480016

[3] Most RESTful APIs aren't really RESTful (564 comments):

https://news.ycombinator.com/item?id=44507076

[4] Braid HTTP:

https://jzhao.xyz/thoughts/Braid-HTTP

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

#336

Post by rogerrogerr »

Aurornis wrote: post #311
crazygringo wrote: post #273

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

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)

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

#337

Post by tylerchilds »

Aurornis wrote: post #311
crazygringo wrote: post #273

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

You can resolve it with an algorithm, like so

- prefer seniority - prefer pay scale - prefer alphabetical - roll dice

That’s how a business would probably do it since the first two alone align with how the business already values their Human Resources, which would translate to “the objects that the Human Resources compete for”

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

#338

Post by ChadNauseam »

VikingCoder wrote: post #49

I want many more Local-Only apps, thanks. Self-Hosted. Or Federated apps, again Self-Hosted. And I think network infrastructure has been holding us back horribly. I think with something like Tailscale, we can make local-only apps or federated apps way, way easier to write.

To me, writing a local-first app using CRDTs is the only way I ever want to build apps from now on. It's by far the most fun approach I've found. And here's why: the CRDTs I work with require you to maintain an event log, AKA a complete history of everything that's happened which you then replay to compute the current state. This allows events from other devices to be inserted at their proper chronological point in the stream, so that when you replay everything you get the correct current state with that event included.

In practice, it has an unexpected benefit. Whenever I hit a decision point where I'm not totally sure how something should behave, I can just ship it anyway without stressing about it. Later on, I can retroactively change how that action works by updating the function that processes events into state changes. It's hard to convey just how liberating this is, but trust me, this situation comes up way more often than you'd expect.

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

#339

Post by jakelazaroff »

fragmede wrote: post #330
robenkleene wrote: post #105

Earlier quoted context omitted.

Excel and Word both support real-time collaboration and sync, e.g., https://support.microsoft.com/en-us/office/collaborate-on-wo...

Google docs is the gold standard here.

Google Docs is not "local" in any meaningful sense of the word.

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

#340

Post by cyberax »

kazinator wrote: post #312
cyberax wrote: post #303

Earlier quoted context omitted.

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…

One solution is to make it so that people see their literal keystrokes in real time. Then they solve the conflict themselves. Like, "stop typing into this text because bob is typing into it". It's like Ethernet conflict resolution: just access the shared medium and detect collisions in real time.

It's fine if you're talking about a text editor or an Excel table. And it's one of the few cases where CRDTs make sense.

If you have a CRM-like application with a list of users? Not so much.

Post reply on HN