5 ms·
What even is “local-first”. I’m a big proponent of being able to run the code locally, but this seems to be more along the lines of, first update some local DB
by nixpulvis 3y ago
What even is “local-first”.
I’m a big proponent of being able to run the code locally, but this seems to be more along the lines of, first update some local DB, then sync it.
I see nothing fundamentally different here than using a well designed API for ‘sync’, and none of it does anything to revive the web browsing experience. Gone are the days where “page load” meant that you could safely begin reading without interruption. This whole “web application” thing was a foobar’d mess. Yes, we probably want some level of interactivity, but I fail to see how casting the web application problem as a database sync issue addresses the fundamental issues.
That being said, I can see the appeal. It’s a clean interface to work with and it allows for new frameworks to displace existing problematic frameworks.
I just worry that in 5 years we’ll all be complaining about poorly designed schema and overloaded table updates again. The solution? Microservices with their own smaller tables which batch updates to the larger system of course!
- LAC-Tech 3y agoIt's local first because you write your data locally, first, then you sync it. As opposed to writing it remotely first. Also how many well designed APIs for sync really exist in the wild? I feel like you need a decent knowledge of distributed systems theory to even understand the problem space. "Last write wins" is a cop out and just means you are throwing away data semi-arbitrarily.
- deleted 3y ago[deleted]
- atoav 3y agoA local first tool, for me is one that works for most productive purposes without any network connection after the initial page load. Having just returned from a multi-day hiking trip without a lot of network coverage I think people don't realize the utility to such things.
- nixpulvis 3y agoI really like this way of thinking about it. I try to advocate for internetless development, so it meshes nicely with that. It also helps me understand the scope of the frameworks. They need to maintain local state akin to saving files locally. It’s just funny to me how we had this as the default mode of operation many years ago, then lost it because everything went to the cloud, and now we’re realizing that was kinda a mistake and we’re trying to fix it in the new environment.
- erhaetherth 3y agoI think most of us knew this was a mistake instantly. Internet was even shoddier 10 years ago.
- tantaman 3y agoThe reasons why everything left an "internetless model" seem to be getting lost to time but I explained some reasoning here in this comment: https://news.ycombinator.com/item?id=37500449 https://news.ycombinator.com/item?id=37500449
- SkyMarshal 3y agoExactly. A great working example is Obsidian. Every version of it - desktop, android, iOS, writes locally first and then syncs to remote (if you’re subscribed to the Sync service, otherwise just writes locally). Other than Sync (and some other optional services like Publish), it is 100% functional without network connectivity.
- atoav 3y agoCall me old fashioned, but why would anybody ever think doing it differently was a good idea? Having it run locally and only sending requests when really needed is a way to make your app feel reliable and snappy. If every ailly button of your app sends out requests that means the snappiness of your whole UI will depend on the mercy of the network gods. Maybe it is the thrill of the gamble?
- lenkite 3y agoLocal first development is a misnomer. It should be local first persistence. All it does it trade-off the complexity of API management against synchronization of distributed persistence.