Not really sure what you mean. I still run emacs locally.
Why haven't local-first apps become popular?
271–280 of 494 posts
Re: Why haven't local-first apps become popular?
#272As a user the simple answer is that I'll always use a regular application instead of a "local-first" web app when I have the ability. "Local-first apps" are the worst of everything - crappy, dumbed down web UI; phoning home, telemetry, and other privacy violations; forced upgrades; closed source, etc. At work, I don't have a choice, so it's Google Docs or Office 365 or whatever. And in that context it actually makes…
Local first isn’t limited to web apps. It’s a style of application development in which you locally store and operate on the data rather than fetching it from a cloud backend every time. For native apps that means a local database or individual files on the file system. > phoning home, telemetry, and other privacy violations; forced upgrades; closed source, etc. This describes proprietary software developed by capita…
I think most native apps (at least that I use) are local first. I can't think of a single one that requires a consistent internet connection to function, that otherwise could run locally. The whole "local-first" trend that has cropped up lately was at least partially influenced by web apps like Linear and Figma, and if you look at the libraries and writing being produced on this topic it's almost exclusively Javascript and about making crud web apps local-first.
Re: Why haven't local-first apps become popular?
#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 remember it turns your data model into a bunch of messages that then need to be constantly reconstructed into the actual current state of data. It's a gigantic enormous headache.
Re: Why haven't local-first apps become popular?
#274Unfortunately the solution presented in the article is locked to a closed cloud offering. I have nothing against those, Firebase for example is like that, but I dislike the fact that it’s hidden. “It’s just an sqlite extension”, oh and it syncs with our commercial cloud offering only. Other vendors like Powersync and ElectricSQL have a similar offering but are upfront about it. And at least in Powersync’s case (don’t…
It's kind of hard for me to think of a devtool as local-first or not, since the actual definition of local-first [1] talks about end-user software, not devtools.
So the question is whether it's possible to build software that adheres to the local-first principles using sqlite-sync.
edit: I'm aware people are using the term "local-first" very loosely, so perhaps my reply here is a bit off-topic
p.s. yes you can self-host ElectricSQL
p.p.s. I really need to keep my list of "sqlite sync" things updated: I have SQLSync [2], SQLiteSync [3] and now SQLite-Sync [4]. Simple!
[1] https://www.inkandswitch.com/essay/local-first/
[2] https://github.com/orbitinghail/sqlsync
Re: Why haven't local-first apps become popular?
#275> One of the simplest CRDT strategies is Last-Write-Wins (LWW): > Each update gets a timestamp (physical or logical). > When two devices write to the same field, the update with the latest timestamp wins. Please also have a robust synced undo feature , so it's easy to undo the thing you don't want that gets written. Apps that sync often seem to be stingy about how much "undos" they store/sync (if any).
Or they save as soon as they launch, so no matter what local is newer and you'll lose whatever was on remote.
Re: Why haven't local-first apps become popular?
#276Perhaps I'm missing something, but aren't local-first apps the overwhelming norm? Like if I think about the apps I use, my friends use etc, most of them are local. Unless the author means "local first web apps", which would make more sense. And I think the oxymoronic nature of a "local first web app" gives a clue as to their unpopularity.
The context should be clear that this is talking exclusively about apps that store their data in the cloud.
Local-first here means starting with a local data model that syncs to the cloud from the start, rather than an app that only works online.
Re: Why haven't local-first apps become popular?
#277Time. If it takes more than like 30 seconds to setup the masses will never adopt it.
Re: Why haven't local-first apps become popular?
#278Because when your selling point is that its local first (or distributed, or any other politically trendy thing), you concentrate on that over the app's core value proposition. The end result is you make an app that does what people think they want at the expense of doing as good a job as possible at the thing people actually want.
When I switched to Immich, I thought I was going to give up a lot for the sake of self hosting. To my surprise, it’s actually better than anything I’ve used from Apple or Google. Unicorns exist, they are just rare.
While Immich is fantastic enough for me to have paid the $100 just to support them, it's self-hosted, not offline-first. The two are different.
Re: Why haven't local-first apps become popular?
#279Bring back gold old desktop applications, I say. Apps are for your phone.
Re: Why haven't local-first apps become popular?
#280> 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…
Agreed @ not for the faint of heart.
There is at least one alternative "CRDT-free" approach for the less brave among us: https://mattweidner.com/2025/05/21/text-without-crdts.html