Local-first software (2019)

(www.inkandswitch.com)

869 points gasull | 1 comments | 05 Jul 25 14:45 UTC | HN request time: 0s | source

Show context

monkeyelite ◴[05 Jul 25 22:59 UTC] No.44476235[source]▶

There is no reason for every application to have its own sync platform. I suspect this framing came out of mobile apps where there is no composability or modularity between programs.

If you really embrace "local first" just use the file system, and the user can choose from many solutions like git, box, etc.

I hate signing up for your sync just as much as any other SAAS, but it's even more opaque and likely to break.

replies(3): >>44476282 #>>44476361 #>>44478944 #

swsieber ◴[05 Jul 25 23:23 UTC] No.44476361[source]▶

>>44476235 #

I agree that not every app needs it's own sync engine, but I disagree with your framing that the file system is the universal way to embrace local first. I have two reasons.

First is that yeah, local first, but I also want concurrency. If it's just local first, you're right, any old sync will do. But I want more than that. I want to not have to think (a la dropbox, being slick). I want my wife and I to be able to make separate edits on our phones when we're in a dead zone.

Second is that sync works a lot better when it has deep knowledge of the data structure and semantics. Git and box both have significant shortcomings, but both exacerbated by the concurrency desire.

replies(2): >>44476392 #>>44479831 #

1. hahn-kev ◴[06 Jul 25 11:39 UTC] No.44479831[source]▶

>>44476361 #

If the app is designed for it you can use a hybrid approach, where a given "document" is stored in 1 file for each client, and the client merges the changes across all files. That way there's never a change conflict that something like Dropbox needs to handle and it can all be offloaded to the app.

↑