28 ms·

Why haven't local-first apps become popular?

• deleted 1y ago
  [deleted]
• PaulHoule 1y ago
  Lotus Notes solved syncing for object databases but the world forgot https://en.wikipedia.org/wiki/HCL_Notes https://en.wikipedia.org/wiki/HCL_Notes
  • mschuster91 1y ago
    Ahhh Lotus Notes... in many ways ahead of its time, timeless and horribly outdated at the same time.
    • echelon 1y ago
      I still remember the crazy password screen with the symbols that changed as you typed. If that was deterministic, that was a very bad idea.
      • AlexandrB 1y ago
        IIRC the symbols were basically a hash of the password that let you know if you typed the password correctly without showing it.
  • codegeek 1y ago
    You just reminded me of the nightmare Lotus Notes was. Great idea but absolutely horrendous implementation. Probably the worst piece of software I have ever used and I have been in the industry for 21+ years now.
  • patwolf 1y ago
    From my time using Notes I remember lots of manual replication config to get anything to properly work offline, and even then I struggled to get it to work reliably. So while they might have solved it, I don't think their solution was very good.
• self_awareness 1y ago
  > Offline-first apps sound like the future: instant loading, privacy by default, and no more spinning loaders on flaky connections. The future? I thought all apps were like this before this web2.0 thing ruined it.
  • threetonesun 1y ago
    What's a little funny to me is that most of Web 2.0 was supposed to solve things like collaborating on a Word doc on a shared server, ideally getting us around the X+1 versions of files problem, but collaboration is a human problem, so now we have X+1 versions, but in the cloud.
  • takluyver 1y ago
    The implied context for that is that whatever information you have in the apps should be kept in sync between devices and between people. Classic desktop applications are more like offline-only. Web 2.0 traded that approach for data living on a server, so it stays in sync because there's only one source of truth, but you can only edit it when online. 'Offline-first' is trying to combine the benefits of both approaches.
• gritzko 1y ago
  The author’s journey is probably just starting. I had this exact mindset about 10 years ago. Long story short: distributed systems are hard. A linear log of changes is an absolute lie, but it is a lie easy to believe in.
  • aleph_minus_one 1y ago
    > distributed systems are hard. While this may be true, the central issue is a different one: most users and/or developers are not very privacy-conscious, so they don't consider it to be worth the effort to solve the problems that go in hand with such distributed systems.
    • deleted 1y ago
      [deleted]
    • Romario77 1y ago
      In the case the author presents there is one solution - last write wins. Which while simple to implement is not really satisfactory for many use cases. Someone could write a whole slew of changes locally and someone else can eliminate all their work because they have an outdated copy locally and they made a simple update overriding the previous person's changes. That's why git has merges and conflicts - it doesn't want to lose changes and it can't automatically figure out what should stay in case of a conflict.
      • fellowniusmonk 1y ago
        I think anyone going down the path of distributed editing would be well served to start with Loro and an instance of chatgpt to answer questions.
  • MangoToupe 1y ago
    > A linear log of changes is an absolute lie Compared to what?
    • 1y ago
• wellpast 1y ago
  It’s a least-common denominator effect. I.e., most people don’t care. Local-first is optimal for creative and productivity apps. (Conversely, non-local-first are terrible for these.) But most people are neither creative nor optimally productive (or care to be).
  • chii 1y ago
    > most people don’t care. it's not that they "don't care", but that they dont know this is an issue that needs to be cared about. Like privacy, they didnt think they need it until they do, but by then it's too late.
• tomxor 1y ago
  > 1. Unreliable Ordering If you think this is only a problem for distributed systems, I have bad news for you.
• api 1y ago
  I feel like a broken record here: it is not an engineering problem. Local-first and decentralized apps haven't become popular because SaaS has a vastly superior economic model, and more money means more to be invested in both polish (UI/UX) and marketing. All the technical challenges of decentralized or local-first apps are solvable. They are no harder than the technical challenges of doing cloud at scale. If there was money in it, those problems would be solved at least as well. Cloud SaaS is both unbreakable DRM (you don't even give the user the code, sometimes not even their data) and an impossible to evade subscription model. That's why it's the dominant model for software delivery, at least 90% of the time. The billing system is the tail that wags the dog. There are some types of apps that have intrinsic benefits to being in the cloud, but they're the minority. These are apps that require huge data sets, large amounts of burstable compute, or that integrate tightly with real world services to the point that they're really just front-ends for something IRL. Even for these, it would be possible to have only certain parts of them live in the cloud.
  • cosmic_cheese 1y ago
    Cloud SaaS services are often extremely heavily marketed, too, often with a VC-backed ad spend pool. That’s difficult if impossible to compete with. There’s also an upcoming generation that doesn’t know what a filesystem is which also doesn’t help matters.
    • deleted 1y ago
      [deleted]
    • api 1y ago
      > There’s also an upcoming generation that doesn’t know what a filesystem is which also doesn’t help matters. This is why I sometimes think it's hopeless. For a while there -- 90s into the 2000s -- we were building something called "computer literacy." Then the phones came out and that stopped completely. Now we seem to have inverted the old paradigm. In that era people made jokes about old people not being able to use tech. Today the older people (30s onward) are the ones who can use tech and the younger people can only use app centric mobile style interfaces. The future is gonna be like: "Hey grandpa, can you help me figure out why my wifi is down?"
• lenerdenator 1y ago
  They're extra work. Now that people are used to having someone in a data center do their backing up and distributing for them, they don't want to that work themselves again, privacy be damned.
• marapuru 1y ago
  I always start with a local first application. And then find that I want to access List X, Design Y, Scribble Z on the road and on my phone. Resulting in a frenzied search for a mobile / desktop alternative that includes syncing. Then finding a solution that requires a subscription and then falling back into fiddling with Google Drive, or something in the Google workspace. I guess I should bring my devices back to exactly 1 device. Or just take a subscription on one service.
• candiddevmike 1y ago
  IMO, offline read-only is enough of a compromise. How many times are users truly offline, AND want to be able to edit at that time (and deal with the potential conflicts, which by the nature of the operation, won't have a good UX)?
  • ComputerGuru 1y ago
    Any time looking at the RO data directly triggers a need to edit it. Eg, you notice a typo or a mistake, you get the idea for a follow up or clarification, etc.
  • arrowtrench 1y ago
    Offline read-only would already be a great feature for me, knowing that my data is always close to machine. But, my guess is that this isn't enough of a killer feature for most people to care.
  • ninalanyon 1y ago
    In my case quite a lot of the time. Which is why Google Keep as a web app is useless but the Android version is very useful. Also I don't understand why so many people on HN are concentrating on the simultaneous editing scenario, for most ordinary people this is actually quite a rare event especially in their private lives. Google Keep on Android seems to work pretty well in his context my family uses it to share shopping lists and other notes very successfully even hough several of us are online only intermittently.
• lordnacho 1y ago
  Local-first was the first kind of app. Way up into the 2000s, you'd use your local excel/word/etc, and the sync mechanism was calling your file annual_accounts_final_v3_amend_v5_final(3).xls But also nowadays you want to have information from other computers. Everything from shared calendars to the weather, or a social media entry. There's so much more you can do with internet access, you need to be able to access remote data. There's no easy way to keep sync, either. Look at CAP theorem. You can decide which leg you can do without, but you can't solve the distributed computing "problem". Best is just be aware of what tradeoff you're making.
  • marginalia_nu 1y ago
    > There's no easy way to keep sync, either. Look at CAP theorem. You can decide which leg you can do without, but you can't solve the distributed computing "problem". Best is just be aware of what tradeoff you're making. Git has largely solved asynchronous decentralized collaboration, but it requires file formats that are ideally as human understandable as machine-readable, or at least diffable/mergable in a way where both humans and machines can understand the process and results. Admittedly git's ergonomics aren't the best or most user friendly, but it at least shows a different approach to this that undeniably works.
    • jjcob 1y ago
      Git works, but it leaves conflict resolution up to the user. It's good for a tool for professional users, but I don't see it being adopted for mainstream use.
      • criddell 1y ago
        How can you avoid leaving conflict resolution up to the user?
      • PaulHoule 1y ago
        The funny thing about it is I see git being used in enterprise situation for non-dev users to manage files, often with a web back end. For instance you can tell the average person to try editing a file with the web interface in git and they're likely to succeed. People say git is too "complex" or "complicated" but I never saw end users succeeding with CVS or Mercurial or SVN or Visual Sourcesafe the way they do with Git. "Enterprise" tools (such as business rules engines) frequently prove themselves "not ready for the enterprise" because they don't have proper answers to version control, something essential when you have more than one person working on something. People say "do you really need (the index)" or other things git has but git seemed to get over the Ashby's law threshold and have enough internal complexity to confront the essential complexity of enterprise version control.
• ForHackernews 1y ago
  If they're building this on top of sqlite, probably worth considering adopting https://rqlite.io/ https://rqlite.io/ that has already done a lot of work for a clustered sqlite
• Xelbair 1y ago
  Technical reasons are honestly overblown - it all boils down to one, business, reason - control. When you do serverside stuff you control everything. What users can do, and cannot do. This lets you both reduce support costs as it is easier to resolve issues even by ad-hoc db query, and more importantly - it lets you retroactively lock more and more useful features behind paywall. This is basically The DRM for your software with extra bonus - you don't even have to compete with previous version of your own software! i want my local programs back, but without regulatory change it will never happen.
  • hobs 1y ago
    Yep at every company I have ever worked at the question is not only how to assert control, but how to maintain it for the long term. Even if the company isn't exploiting you today, they want the option for later.
  • gwbas1c 1y ago
    > Technical reasons are honestly overblown Having built a sync product, it is dramatically simpler (from a technical standpoint) to require that clients are connected, send operations immediately to central location, and then succeed / fail there. Once things like offline sync are part of the picture, there's a whole set of infrequent corner cases that come in that are also very difficult to explain to non-technical people. These are silly things like: If there's a network error after I sent the last byte to a server, what do I do? You (the client that made the request) don't know if the server actually processed the request. If you're completely reliant on the server for your state, this problem (cough) "doesn't exist", because when the user refreshes, they either see their change or they don't. But, if you have offline sync, you need to either have the server tolerate a duplicate submission, or you need some kind of way for the client to figure out that the server processed the submission.
    • Xelbair 1y ago
      but it is nothing that cannot be solved - if it was more profitable we would all be doing it.
• hasanhaja 1y ago
  I've only started playing with local first recently to learn the Service Worker API and IndexedDB, and I'm looking forward to learning about CRDTs more. Here's a little todo app that I built: [1] GitHub: https://github.com/hasanhaja/tasks-app/ https://github.com/hasanhaja/tasks-app/ [2] Deployed site: https://tasks.hasanhaja.com/ https://tasks.hasanhaja.com/
• radarsat1 1y ago
  I spent some time learning about PouchDB a little while ago, it seems to be a nice solution at least for a No SQL approach. Although I still need some more practical experience to understand the security model, because it feels weird to just sync a database that was updated on some web page, really you want to ensure there is validation and treat it as an untrusted source to some extent. Still not sure of the best way to deal with that without implementing most of the application as server side validation scripts, or maybe that is just the way to do it.
• jakelazaroff 1y ago
  The real answer to the question isn't technical. Local-first apps haven't become popular because companies recognize that their value comes from controlling your data. In a talk a few years ago [1], Martin Kleppman (one of the authors of the paper that introduced the term "local-first") included this line: > If it doesn't work if the app developer goes out of business and shuts down the servers, it's not local-first. That is obviously not something most companies want! If the app works without the company, why are you even paying them? It's much more lucrative to make a company indispensable, where it's very painful to customers if the company goes away (i.e. they stop giving the company money). [1] https://speakerdeck.com/ept/the-past-present-and-future-of-local-first?slide=15 https://speakerdeck.com/ept/the-past-present-and-future-of-l...
• xorvoid 1y ago
  I believe the lack of popularity is more of an economics problem. There are established business models for SaaS apps or freemium with ads. But, the business model for local-first apps is not as lucrative. Those who like the local-first model value features like: data-sovereignty, end-to-end encryption, offline usage, etc. These properties make existing business models hard-to-impossible to apply. My current thinking is that the only way we get substantial local-first software is if it's built by a passionate open-source community.
  • canpan 1y ago
    Yes, I don't think replicated data structures are the problem. Look at single player video games, cannot get more ideal for local-first. Still you need a launcher and internet connection.
    • SilverbeardUnix 1y ago
      No you don't. There are plenty of games you can buy and go into the wilderness and play just fine offline. Just because game developers WANT you to be online so they can get data doesn't mean you NEED to be online.
      • Reubachi 1y ago
        Your point is correct, but OP is correct. There are currently tens of thousands of games that are unplayable due to requiring pinging to a network/patch server which long ago was deprecated. Forsaking patch requirements, just as many games are no longer playable due to incompatibility/abandoned OS, codebase, gamebreaking bugs. In both of these scenarios, my "lifetime license" is no longer usable through no action of my own, and breaks the lifetime license agreement. I shouldn't need to be into IT to understand how to keep a game I bought 5 years ago playable. The solution to this "problem" for user, as offered by the corporate investment firms in control, is to offer rolling subscriptions that "keep your license alive", for some reason. Rather than properly charge for a service at time of purchase. TLDR: Why move the goal posts further in favor of tech/IT/Videogame Investment firms?
• wartywhoa23 1y ago
  Because Big Money are behind Local-Last Apps
• rkapsoro 1y ago
  The use case I always think of is the developer experience for regular hobbyist and workaday devs writing their apps with local-first sync. Apple comes close with CloudKit, in that it takes the backend service and makes it generic, basically making it an OS platform API, backed by Apple's own cloud. Basically cloud and app decoupled. But, the fundamental issue remains, in that it's proprietary and only available on Apple devices. An open source Firebase/CloudKit-like storage API that requires no cloud service, works by p2p sync, with awesome DX that is friendly to regular developers, would be the holy grail for this one. Dealing with eventually consistent data models is not so unusual these days, even for devs working on traditional cloud SAAS systems, since clouds are distributed systems themselves. I would be very happy to see such a thing built on top of Iroh (a p2p network layer, with all the NAT hole punching, tunnelling and addressing solved for you) for example, with great mobile-first support. https://github.com/n0-computer/iroh https://github.com/n0-computer/iroh
  • lifty 1y ago
    Off topic, but why would I choose iroh instead of libp2p which seems to have much better language coverage compared to iroh?
  • marcusestes 1y ago
    Your holy grail is probably Fireproof: https://fireproof.storage/ https://fireproof.storage/ Open source, uses object storage without a web server dependency, syncs, and has great DX.
• gizmo 1y ago
  I think that the database layer is the wrong layer for reconciliation of change sets. The main problem with any sync system that allows extensive offline use is in communicating how the reconciliation happens so users don't get frustrated or confused. When all reconciliation happens as a black box your app won't be able to do a good job at that.
• PLenz 1y ago
  Harder to rent-seek with non-saas software
• robmccoll 1y ago
  I wonder about the categories of apps for which offline first with potentially infinitely delayed sync provides a better experience and how large those really are. It seems like most of those are apps where I'm creating or working on something by myself and then sharing it later. The online part is almost the nice-to-have. A lot of other apps are either near-real-time-to-real-time communication where I want sending to succeed or fail pretty much immediately and queueing a message for hours and delivering it later only creates confusion. Or the app is mostly for consuming and interacting with content from elsewhere (be that an endless stream of content a la most "social media", news, video, etc. or be it content like banking apps and things) and I really mostly care about the latest information if the information is really that important at all. The cases in those apps where I interact, I also want immediate confirmation of success or failure because it's really important or not important at all. What are the cases where offline-first is really essential? Maybe things that update, but referencing older material can be really useful or important (which does get back to messaging and email in particular, but other than something that's designed to be async like email, queueing actions when offline is still just nice-to-have in the best cases). Otherwise the utility of CRDTs, OT, et al. is mostly collaborative editing tools that still need to be mostly online for the best experience.
  • blacklion 1y ago
    > It seems like most of those are apps where I'm creating or working on something by myself and then sharing it later. It is interesting. I've thought about things I don in non-messaging apps (which are online0first for obvious reasons), and all of them create something, which can be EXPORTED to on-line presence, but doesn't require connected app. Code? I write it locally and use separate app to share it: git. Yes, code is collaborative creation (I'm working in the team), but it is still separate tool and I like it, as I control what I'll publish for my colleagues. Photos? Of course I want to share result, but I'm working on RAW files with non-destructive editing and I want to share final bitmap (as JPEG) and not RAW data and editing steps. Same with music, if I create one (I doesn't). Texts must be polished in solitude and presented as final result (maybe, as typographically set one, as PDF). All my "heavy" applications are and should be offline-first!
• codeulike 1y ago
  Every problem is a sync problem these days. Sync problems are harder than just 'use a CRDT'. What counts as 'consistent' depends on the domain and the exact thing that is being modelled.
• luplex 1y ago
  Apps that let you manipulate artifacts are often local. MS Office, Photoshop, Blender, CAD tools. But it turns out that actually, humans rarely work or live alone, and you can't facilitate communication through a local-first app.
  • Sharlin 1y ago
    Yet somehow people managed to do that before everything went to the cloud.
  • ninalanyon 1y ago
    Surely an email client like Thunderbird is local first? Even the email apps on mobile devices work offline and send and receive when the get a connection.
• syntaxing 1y ago
  It’s a hard balance, local first a lot of times feel local only. I really like the model on Home Assistant/Nabu Casa. Local first and you can pay a subscription to cloud access.
• rco8786 1y ago
  [flagged]
• gejose 1y ago
  Shameless self plug, but my workout tracking app[1] uses a sync engine and it has drastically simplified the complexities of things like retry logic, intermittent connectivity loss, ability to work offline etc. Luckily this is a use case where conflict resolution is pretty straightforward (only you can update your workout data, and Last Write Wins) [1] https://apps.apple.com/us/app/titan-workout-tracker/id6449496844?platform=iphone https://apps.apple.com/us/app/titan-workout-tracker/id644949...
  • pbronez 1y ago
    Which sync engine are you using?
• elzbardico 1y ago
  Network speeds are of sufficient bandwidth and latency to allow cloud first applications, which are vastly simpler to develop than Local-first whenever you need to add any remote/collaborative feature.
  • johannes1234321 1y ago
    > Network speeds are of sufficient bandwidth and latency They are, as long as you in reach of a base station. As soon as you travel through a tunnel, hike outside, are on an airplane or are in Australia with latency to U.S or European servers things are different. Not to mention choice of being offline, either to disable distraction or for reducing roaming costs for some devices while travelling.
• kachapopopow 1y ago
  I don't understand why we have servers in the first place for any kind of local appliance, they ARE a server already, 256mb of flash costs pennies for storing hundreds of thousands of metrics - almost enough for a year!
  • kachapopopow 1y ago
    Not sure why this is getting downvoted I assume because it has nothing to do with the article but these problems don't exist in applications that never have to reach a server in the first place. Remote access can be solved with a simple relay appliance (ex what homepod does for apple) for the average joe.
• VikingCoder 1y ago
  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.
  • hasanhaja 1y ago
    I've been having fun exploring this actually: https://news.ycombinator.com/item?id=45333494 https://news.ycombinator.com/item?id=45333494 I've found it to be a fun way to build apps.
  • michaelsalim 1y ago
    Agreed. I'm building a presentation software[1] so it needs to work locally (can't afford lost of connection). But I also want it to be accessible from anywhere. Unfortunately those two things don't mesh that easily. The tech is getting there though. With things like hole punching or webrtc, P2P is getting pretty easy to implement. Though it's still a challenge to implement it in an actual project. I do believe that we're going to start seeing quality local-first software w/ great networking pop up more and more soon. I'm working on that, but I'm sure there are plenty others who are doing the same. [1] Open-source, see my profile for info
    • VikingCoder 1y ago
      Really, why not use Tailscale?
      • michaelsalim 1y ago
        Never said you shouldn't. Tailscale uses a bunch of different techniques including hole punching for it to work. If that's what you need, go ahead. I opted for Iroh for a few different reasons but Tailscale is an awesome choice too.
  • ChadNauseam 1y ago
    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.
• ktosobcy 1y ago
  I try to use those as much as possible. We ended up in this situation mostly because of the Google push to make everything an "web-app" with web-technologies instead of protocols... Anyone uses IMAP email? Works just fine (save for IMAP design but that's another story). Same with CalDAV. For stydy I use Anki and it has brilliant sync (it can even automatically/automagaically merge study changes when I study some items on mobile and others on desktop). Many seem to claim that it's impossible to sync correctly in "colaborative environment" as in it would always involved dozens of people constantly working and editing the document (which would be utterly difficult to track the evolution of)… Most of the time it's not that colaborative and having the data locally makes it easier to work with. OTOH not everything has to be (web-)app…
  • jjcob 1y ago
    IMAP works fine until you try to continue working on a draft email that you started on another computer... somehow it always gets broken and I end up with 5 copies of the message in the drafts folder...
    • isaachinman 1y ago
      We fixed this at Marco, FYI. https://marcoapp.io https://marcoapp.io
      • jjcob 1y ago
        How?
  • Anonyneko 1y ago
    With Anki the sync works perfectly until it doesn't and the app asks you to choose the copy you want to keep. Thankfully it doesn't happen often and hasn't caused any trouble for me, but it (seemingly) has no options for manual conflict resolution.
    • ktosobcy 1y ago
      Hmm... it requires full sync if you edit the fileds of template. In the past it required full sync due to conflict but in the last ~2 years (maybe) I haven't run into such probelm (I guess periodic sync in the background eliminating to much of a backlock probably helps)
• cramcgrab 1y ago
  Because cloud. And local hardware and software lags now.
• anon1395 1y ago
  Personally I think PWAs are a bit confusing for consumers as they think "It's a website, i won't be able to use it offline." and if they get reminded that they can use it offline they usually forget.
  • alextingle 1y ago
    Why would they think "its a web-site"? PWAs just look like normal phone apps. In fact, many "normal" phone apps are basically just a web-site inside a thin wrapper. So the difference is largely academic in many cases.
    • crote 1y ago
      Because a user first encounters it on the web - where it acts exactly like a website. The only difference is that the bookmark-button-thingy says "add app to home screen" instead of "add to home screen". It's not giving a "I'm installing an application" vibe, it is giving "I am creating a shortcut to a website" vibes. Apps are installed via the app store, not as weird quasi-bookmarks in your browser.
    • anon1395 1y ago
      Most ordinary people thing that they are just adding a shortcut to the website, whereas these wrappers convince the user they are actually installing an app app.
• Andrew_nenakhov 1y ago
  Server-centric computing is just more efficient, and it usually becomes less popular only at because means of communication aren't up to the task at the moment. 1. In the beginning, there were mainframes and terminals. You saved resources by running apps on a server and connecting to them with cheap terminals 2. Then, PCs happened. You could run reasonably complex programs on them, but communication capabilities were very limited: dialup modem connections or worse 3. Then, internet happened, and remote web apps overtook local apps in many areas (most of those that survived required massive usage of graphics, like games, which is difficult even with modern internet) 4. Then, smartphones happened. At the time of their appearance they didn't have ubiquitous network coverage, so many first apps for these platforms where local. This is eroding too, as communication coverage improves. So if you look at this, it is clear that main share of computing oscillated back and forth between server and local, moving to local only when communication capabilities do not permit remote running, and once comms catch up, the task of running apps moves back to servers.
• setnone 1y ago
  Just because "personal server" hasn't happened yet in the way personal computer did
  • RajT88 1y ago
    That is an interesting thought. How do you make self-hosting appealing to more than weird nerds?
    • crote 1y ago
      Make it a comprehensive service you can rent at a fixed monthly cost. Which of course defeats the whole "self-hosting" part. Regular people don't like the Magic Box Which Makes Things Work. They'll begrudgingly shove it in a cupboard and plug it in, but even that is already asking a lot. If it needs any kind of regular maintenance or attention, it is too much effort. "Plug in a harddrive once a month for backups"? You'll have just as much asking them to fly to Mars and yodel the national anthem while doing a cartwheel.
• SilverbeardUnix 1y ago
  1. People don't work alone and need to collaborate 2. People value convenience over privacy and security 3. Cloud is easy.
  • RajT88 1y ago
    Do not forget - cloud makes apps easier to monetize via ads and selling user data. Business trumps perfect software engineering almost every time.
  • weego 1y ago
    Absolutely. I can't believe so many replies are struggling with the easy answer: privacy, security, "local first", "open source", "distributed", "open format" etc etc etc are developer goals projected onto a majority cohort of people who have never, and will never, care and yet hold all the potential revenue you need.
  • arrowtrench 1y ago
    Is local-first bad / more difficult for collaboration because of conflict resolution? (E.g., two users edit the same document when they're offline and then, during syncing, they find that their versions diverge too much for them to be merged cleanly.) If so, isn't it possible to mark certain assets as "undivergable" which would effectively mean that the program would act like a traditional cloud-first type of app for that specific asset? This middle ground could introduce too much complexity and some inconsistency, but it could prove useful in certain cases.
    • jonathanstrange 1y ago
      Merge conflicts arise just as easily in a cloud-first app than in a local-first app once you go beyond any simple "last edit wins" consistency model (and if you have that model, it's also no problem for local-first). What counts as a conflict depends entirely on the data domain in both cases, and that's the hard part. It's just easier to implement cloud-first because it's just CRUD with a centralized database on a server. It's still extremely hard to reliably connect two apps directly peer to peer without some centralized server as an intermediary and since you need a centralized server anyway and in addition have to do the peer to peer syncing, "local first with syncing" is inherently more complex than just syncing to a master database. But potential merge conflicts are the same in both.
• sylens 1y ago
  There's no money in making a local first app. Businesses want your data, they want you to be dependent on them, and they want to be able to monetize your behavior and attention
  • zsoltkacsandi 1y ago
    There is money in local first apps, businesses are just greedy.
  • JustExAWS 1y ago
    Today you can still buy Microsoft Office as a one time purchase.
    • Loughla 1y ago
      But it still prompts you to sign into your account and "finish setting up Windows" by using onedrive and whatever other cloud bullshit. And it will continue to do that forever. Source: when we lose power and the machine restarts unexpectedly, I die a little inside when it goes to the windows set up screen just because I haven't signed in to a Microsoft account.
      • JustExAWS 1y ago
        Do you care about not having a subscription? If so that solves that problem. But in 2025, I have three devices where I for whatever reason may want to have access to my document - my phone, tablet and personal MacBook. That’s not even counting in a pinch, editing on the web if I’m at another trusted computer or on my work computer.
  • observationist 1y ago
    They want everything to be cloud applications and services that run on terminals you rent, managed through portals you have subscribe to. They want to sell your attention and screenshare on top of making you pay for the privilege of being nickel and dimed, and they want to surveil every aspect of your life, free from liability or accountability for what they do with the data, or who they sell it to.
• russnewcomer 1y ago
  I'm not sure CRDTs are actually the right answer here for your example of #2, Marco. A double-entry accounting system might actually be more ideal. In that case, what you are keeping in sync is the ledger, but depending on your use-case, that might actually be easier since you can treat them as a stream-of-data, and you would get the 'correct' answer of 100. In this case, you would need two accounts, a credit and debit account, and then device A would write +20 to the credit account and -20 to the debit account, device B would write -20 to the credit account and +20 to the debit account, then using a HLC (or even not, depending on what your use-case is again), you get back to the 100 that seems from the description of the problem that it is the correct answer. Obviously, if you are editing texts there are very different needs, but this as described is right in the wheelhouse of double-entry accounting.
  • michaelsalim 1y ago
    That's not what a double-entry accounting system is for. If all you're doing is keeping track of one account/balance, then double-entry doesn't add anything. You might want to still implement it that way for future proofing though if you're implementing an accounting system. The main thing to takeway is to store transactions like you mentioned (+20, -20). And in the simplest case, just apply all of them based on time.
    • russnewcomer 1y ago
      You're not entirely wrong that double-entry accounting doesn't add much to keeping track of one balance. And the example provided in the article was very simple, just like mine was very simple. Transactions do help, but if you are trying to keep track of a balance and understanding how that balance is changing, double-entry accounting is helpful.
• Sharlin 1y ago
  > Offline-first apps sound like the future ...and here we go again. Time is a flat circle.
• OfflineSergio 1y ago
  I’ve been working on https://with.audio https://with.audio which is a local app. I think there should be way more local apps with sync capabilities. I haven’t finished the sync feature in WithAudio and you have very nice ideas there. Specially the eventual consistency. That’s what will work. But I must say for sure the most difficult part of local apps is debugging customer issues. For someone who is used to logs and traces and metrics and most of users using a one version of the code in the backend, debugging an issue in customers computer on an old version without much insight (without destroying all your premises of privacy) is very challenging.
  • em-bee 1y ago
    i recently discussed the development of a new application for a customer. one of the important aspects was that the app would handle data that would have to stay local. despite that my thinking went like this: if i develop it as a webapplication, then i can do all the work on my computer, test with various browsers and deliver a working result. if the customer has issues, i can likely reproduce them on my machine. but if it was a desktop application, my feeling was that testing would be a nightmare. i would have to set up a machine like my client, or worse visit the client and work with them directly, because my own machine is just to different from what the client uses. also not to forget distribution and updates in short: web -> easy. desktop -> difficult.
• jlarocco 1y ago
  As 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 sense to have data stored on some server somewhere because it's not really my data but the company's. But at home I'll always choose the strictly offline application and share my data and files some other way.
  • em-bee 1y ago
    "Local-first apps" are the worst of everything - crappy, dumbed down web UI along with no privacy. which apps are you talking about here? that description doesn't make any sense to me.
    • jlarocco 1y ago
      Aren't "local-first apps" in this context the ones where you vist "example.com", and it caches a bunch of HTML and Javascript and saves data locally using the "local storage" APIs? And then periodically makes requests back to "example.com" to check for updates, sync data, etc.?
      • shortercode 1y ago
        Kinda yes kinda no? Most PWAs have some idea of offline support but it tends to be an afterthought. The argument of local first is that you design the app to work against a local database ( normally stashed in indexeddb or OPFS ) meaning that you don’t have to wait for data to load or network requests to complete. Your backend is then just a dumb storage engine which accepts changes and sends push messages to the client to indicate things have changed. The only “big” local first app I’m aware of is Linear.
      • miladyincontrol 1y ago
        While I hesitate to agree with that definition of local-first, I agree with your notion thats what the author by large is talking about and unfortunately many such an web-app have the worst of both worlds. Most uses of the term local-first I see regularly mean to say, "an app that doesnt require 3rd party servers outside of your control to function", within some level of reason. Sometimes agnostic to how it's data is synced, sometimes meaning its an exercise left to the user entirely, sometimes meaning fully self-hosted and hardly local to the device being used to access the app.
• MathMonkeyMan 1y ago
  The free software evangelist in me says "because local-first gives more to the user of the software," which will tend not to happen when the user is not in control of the software. Realistically the reason is probably that it's easier to make changes if you assume everything is phoning home to the mother ship for everything. Also, an unrelated nit: "Why Local-First Apps Haven’t Become Popular?" is not a question. "Why Local-First Apps Haven’t Become Popular" is a noun phrase, and "Why Haven't Local-First Apps Become Popular?" is a question. You wouldn't say "How to ask question?" but instead "How do you ask a question?"
  • robenkleene 1y ago
    Apple is practically the most antithetical to "free software" company around, yet Apple maintains perhaps the largest fleet of local-first apps in existence, e.g., off the top of my head: Calendar, Contacts, Keynote, Mail, Notes, Numbers, Photos, and Pages (these are all examples of apps that support multi-device sync and/or real-time collaboration). I think the truth of your statement is more that free software tends towards what you might call "offline" software (e.g., software that doesn't sync or offer real-time collaboration), because there's more friction for having a syncing backend with free software.
    • dredmorbius 1y ago
      Apple sells hardware. (And, increasingly, entertainment and services.) Software is a positive complement to those revenue sources.
    • jkaplowitz 1y ago
      The Windows desktop version of Microsoft's suite is probably bigger, more widely used, and just as local-first than Apple's suite, with the exception of the new version of Outlook that's still very far from replacing the traditional and local-first version. (They haven't tried to do any such replacement of the rest of their suite.)
    • MathMonkeyMan 1y ago
      Maybe the distinction is in that word "app." We started calling programs "apps" when smart phones came out. Smart phones are remote-first, and it makes sense (or it did) as long as you think of a phone as your terminal into... something. Your examples are all programs that predate mobile, even though they are available on mobile (are they local-first on mobile too?).
• brainzap 1y ago
  Does Apple Notes count as local first? it is an amazing experience.
• czx111331 1y ago
  I believe that in the right contexts—specifically where eventual consistency is acceptable—the local-first paradigm is highly valuable and will gradually become mainstream. A major factor limiting adoption today is that existing local-first solutions are incomplete: when building such applications, developers must handle many problems that are trivial under strong-consistency or traditional models. This raises the learning cost and creates significant friction for paradigm shifts. Our recent work on Loro CRDTs aims to bridge this gap by combining them with common UI state patterns. In React, developers can keep using `setState` as usual, while we automatically compute diffs and apply them to CRDTs; updates from CRDTs are then incrementally synced back into UI state [1]. This lets developers follow their existing habits without worrying about consistency between UI state and CRDT state. Paired with the synchronization protocol and hosted sync service, collaboration can feel as smooth as working with a purely local app. We’ve built a simple, account-free collaborative example app[2]. It only has a small amount of code related to synchronization; the rest looks almost the same as a purely local React app. [1]: https://loro.dev/blog/loro-mirror https://loro.dev/blog/loro-mirror [2]: https://github.com/loro-dev/loro-todo https://github.com/loro-dev/loro-todo
  • canadiantim 1y ago
    Loro is very cool. I'm currently testing out building with it. Hadn't seen loro-mirror before, looks very nice too. Is loro-mirror supposed to be used with rich text editors like prosemirror, etc.? Thanks for your great work with loro
    • czx111331 1y ago
      loro-prosemirror[1] offers much better support for integrating Loro with ProseMirror/Tiptap. In theory, loro-mirror could also be used to integrate Loro with other rich-text editors, but that wasn’t its original design goal and it may need further refinement to work well. [1] https://github.com/loro-dev/loro-prosemirror https://github.com/loro-dev/loro-prosemirror
• poisonborz 1y ago
  The goals have shifted. What is "local" nowadays? ~Everybody uses multiple devices, and things are expected to be in sync. What users now (should) need is easy self-hosting apps and centralised storage, with clients that can work/cache offline locally. A good example is Bitwarden.
  • carlosjobim 1y ago
    What problem are you solving with that? I can not think of a single workflow that would be advantaged by self-hosting apps vs using local apps with sync.
    • poisonborz 1y ago
      I meant both. What do you sync with if no central server (main client)? Anything else is unreliable, on/off all the time. And some simpler workflows don't need native apps.
      • carlosjobim 1y ago
        Both what? What problem are you solving?
        • poisonborz 1y ago
          I don't really get "local apps with sync". Sync to what, each other? In most cases there needs to be an always-on central authority (where backup also happens). My point is that "some device sitting alone in a corner with software and data stored on it" model is outdated (this is the "problem", I hope the "why" is obvious). But "local" should live on, just in the form of users owning most of their infrastructure.
          • carlosjobim 1y ago
            Sync through iCloud or through the app manufacturers servers. Most apps I use are real apps that live on my local device. Then some of them sync through iCloud if I want to use sync. This is something I as the user can enable or disable in the app, and it costs me no subscription fee. I think that this is much superior to using fake apps that live on some web server. It comes with great drawbacks even when it is on the web server of the app manufacturer. Ten times more pain if I have to host it myself.
• mhuffman 1y ago
  Some people might say that the browser you are using to look at your webapp or ask chatgpt for something is a local-first app ... making it pretty damn popular.
  • pixelpoet 1y ago
    That's a bit like saying we live in outer space because earth is in outer space.
    • trashb 1y ago
      no, this does not make sense. The "outer" in outer space suggests an inner space. In this case earth because we have historically held a earth centrist view since humans primarily live on earth. The case that earth is inside of outer space is assumed. Also I believe the original comment is right as your browser (HTTP) operates fundamentally on a request reply basis. You request resources, you receive an answer, while you are displaying the most recent answer the state on the server might change. You can have a browser that caches the resources for you and only retrieve the new state after for example a timeout or for example a archiving proxy.
      • pixelpoet 1y ago
        Yes, and being a web browser that accesses websites from the internet doesn't make sense to call "local first"; the internet isn't local.
        • trashb 1y ago
          I can browse my private my-site.html perfectly without ever having a network adapter in my device. Now granted some modern webapps (chatgpt) are not designed to operate locally, but there are plenty of webapps that work fine from local storage. A browser is (in my definition) a tool to display what you call a websites, usually a collection of html/css/js resources. One of the options is to retrieve the resources through the network, if you want the latest news for instance. But it is not required and that makes it local-first in my view. I don't think local first means the app can not connect or sync with a remote server. In the same way as saying we live on earth doesn't mean we are not in space, earth is in space and we are on earth. It is not mutually exclusive.
• andsoitis 1y ago
  Lotus Notes and later Groove Networks (both brought to us courtesy Ray Ozzie) both provided a platform to create apps with data synchronizing as a first-class citizen. The technology behind Groove now powers OneDrive and Microsoft 365. Notes: https://en.wikipedia.org/wiki/HCL_Notes https://en.wikipedia.org/wiki/HCL_Notes Groove: https://en.wikipedia.org/wiki/Groove_Networks https://en.wikipedia.org/wiki/Groove_Networks
  • gorfian_robot 1y ago
    Groove was cool for a hot minute before MS got their grubby hands on it
    • flymasterv 1y ago
      I had my first internship at Groove. I did a ton of the I18n work, and something with the chess demo.
  • GMoromisato 1y ago
    I was a developer on both Lotus Notes and Groove, and I think both died for different reasons. Notes was replaced by the web (and Outlook). Notes was, IMHO, ahead of its time. It was one of the first client-server systems where the client was treated as a full peer in the network. You could work offline for as long as you wanted and then the client would automatically synchronize with the server. It had military-grade encryption, a built-in development environment, integrated full-text search, and programmable agents for scheduled data processing, alerting, etc. But the web was much cheaper and benefited from network scaling laws (the more sites, the more value it accrued). The web is a perfect example of "worse is better". The complexity of Lotus Notes kept the price high (both financially and in terms of time-commitment). For Groove we doubled-down on peer-to-peer synchronization. Notes had synchronization at the "note" level. If two people edited the same note while offline then there were conflicts that had to be resolved manually. In contrast, Groove had custom synchronization systems for different kinds of data. For text files we could synchronize at the character level. Other data structures could synchronize at whatever level was appropriate. We used a change-log merge system, not too different from block chain. The problem with Groove was that the advantages (offline editing) never compensated for the disadvantages (lower performance, lack of visibility in sync state, and difficulty in onboarding). The use cases that really needed Groove were rare, and not enough to build a viable business.
• dboreham 1y ago
  While the article is about eventual consistency, the real reason local web apps haven't become popular is that current browsers don't support them. Any code running in the browser has to come from some url. The server at that url is assumed to control everything. Any data stored locally might vanish any time, and can't be accessed by code loaded from any other url. So while you might like the idea of "just running code on my computer via the browser to do something useful" what you're actually doing is providing a way for whoever controls the web server to do whatever they want on your computer (modulo what Google wants). Since any idea of an independent app running on your computer is a fiction, there's no need to even attempt to solve the eventual consistency problems. Just have the server that's in total control do your consistency.
• 0xffff2 1y ago
  I feel like I'm taking crazy pills. How on Earth could anyone consider the example in #2 "conflict-free"? You haven't removed the conflict, you're just ignored it! Anything can be conflict free in that case. Obviously not every problem will have such an obvious right answer, but given the example the author chose, I don't see how you could accept any solution that doesn't produce "100" as a correct result.
  • WorldMaker 1y ago
    I also think this is a place where CRDTs in general got stuck on the name "Conflict-Free" for way too long assuming it was fate that if they worked hard enough they find the magic data structures to eliminate conflicts altogether but real life data is a lot more more complicated than that and real life expectations of data semantics that a data type itself can't encode. I think we are just now getting to the point of seeing CRDT libraries understand some conflicts happen, and some conflicts still need to bubble up to a more complex semantic model or even/especially a user. I don't think there are any CRDT libraries that are strong for that yet, but the work seems to starting into those next steps at least.
    • dwaltrip 1y ago
      I remember like 10 years ago seeing some people getting really excited by CRDTs. I was deeply confused about how the software would magically know what the correct thing to do would be when 2 people made edits that directly conflicted with each other… You can’t know what to do without talking to the people involved, as they have to decide what makes sense for end goal. It’s mostly a social / collective action problem, not a purely technical one.
      • WorldMaker 1y ago
        Yeah, it's hard to fault people from wanting to find as many technical solutions as possible to reduce social problems to a minimum. I can fault CRDTs for thinking that they could solve all of them technically, enough so that they put "conflict-free" in the name, because yeah, there are always problems you can't solve technically, there is always user knowledge you can't just assume the technically best approach is the semantically, socially, or even politically best approach (again as much as we might want to wish that we could solve these things technically, which is a beautiful dream sometimes).
• jrm4 1y ago
  Ideas like this miss the mark when they don't factor in "the forces against us?" This isn't like choice of fast-food burger where it's slightly harder to drive further to get something a little better; nearly the entire economy of Silicon Valley et al works every day to stop and slow down things like "local first."
• pbronez 1y ago
  This is content marketing for a open-source SQLite extension called `sqlite-sync` [0]. It seems pretty cool, implementing CRDTs and some networking directly in SQLite. Unfortunately this extension "is tightly integrated with SQLite Cloud." It doesn't support peer-to-peer syncing or self-hosting a central source of truth. The project is really just a client for the sqlite.ai cloud service. [0] https://github.com/sqliteai/sqlite-sync https://github.com/sqliteai/sqlite-sync
• pbronez 1y ago
  There's a bit of No True Scottsman happening here. Isn't every iOS app backed by iCloud's CloudKit [1] a "Local First App"? [1] https://developer.apple.com/icloud/cloudkit/ https://developer.apple.com/icloud/cloudkit/
• afavour 1y ago
  The primary reason IMO is simply that users don’t care that much. If they did, offline functionality would be a selling point. But it isn’t, and it isn’t immediately simple to implement, so it isn’t worth it.
• trashb 1y ago
  This is not a systems issue this is a UI issue, the state status needs to be communicated to the user. It is ridiculous to retrofit locally first to a app that pretends to the user that it is always online. Social media could allow you to make posts as a "draft" and automatically send it when you have a connection think of a email outbox. Or even give you a notification if after syncing with the master and it turns out the comment you replied to changed. If you look at the web a lot of older (fundamental)protocols and applications have local-first build in. Often the design requirements required communication over a connection that is not as available. A few I can think of of HTTP, EMAIL, FINGER, GOPHER, FIDONET, NEWGROUP and more. A shared state is managed for a lot of different domains (code, gaming, chat, message boards) so I feel like it is already quite a solved problem, but there is no one size fits all solution. IMHO that's the sane thing to do for a networked application as you can never grantee that either party is available, and you want to still serve your user the best you can. It can also have huge benefits for the data provider, especially at scale. - You can lower your bandwidth required drastically. - You can keep a consistent state for your user. - If you are evil you can send a lot more telemetry data or valuable (harvested) data instead. the LWW is only really useful if you have a value where you can discard the previous updates for the latest, it's a bit like using UDP instead of TCP for communicating your position in a multiplayer game. Or if you don't mind forcing your user to resubmit.
• Fire-Dragon-DoL 1y ago
  Because lock in and walled gardens was my assumption
• kelvinjps 1y ago
  I think just doing files and then syncing the files with another solution it's okay. For example my local apps: Synthing syncs the files between my computer and phone for Note taking(just markdown and org files) obsidian on my phone, emacs/vim on my PC. Todo and reminders: org mode in emacs (desktop) orgzly on mobile. Password manager: KeePassxc desktop, keepassdx mobile. Calendar: just sync the ics file. Photos: just sync files use the default app. I can continue with this with every app, I don't know why people overcomplicate things
  • R_Spaghetti 1y ago
    This is the reason why I'm reading this site - this is such a brilliant idea, super simple and without any vendor lockin at all.
  • aborsy 1y ago
    I second Syncthing, it’s amazing!
  • rpdillon 1y ago
    Been doing this for years. It's so utterly amazing and effective.
  • fruitworks 1y ago
    What do you use to integrate ICS into your phone's calendar. This is what i'm suck on. Apps like icsx5 are read-only for ics
  • kevincox 1y ago
    The problem is that this has effectively no conflict resolution. With naive file-based sync the best Syncthing can do is save both files. Then you are stuck merging yourself. Maybe if all of your devices are reliably online and you only use one at a time. But eventually you get a delayed sync resulting in a state fork and you end up with a mess. For photos and some other type of data this likely isn't much of a problem. But for more complex data it definitely is.
    • kelvinjps 1y ago
• reclusive-sky 1y ago
  I've been working on a local-first distributed app and found it difficult to design something that is easy to install and maintain. Important prerequisites and user-managed dependencies (i.e. Redis, Docker) are nonstarters for most potential users. It seems cloud hosting is always the end-state when trying to optimize primarily for less-technical users. FWIW I also ended up arriving at CRDTs as the solution for my app.
• xvrqt 1y ago
  >The reason is simple: syncing is hard. The reason is simple: control is how you extract rent
• bawolff 1y ago
  Because 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.
  • WD-42 1y ago
    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.
    • brianpan 1y ago
      > Why haven't local-first apps become popular? The Immich "Quick Start" step 1 is mkdir and wget commands. Step 2 is "Populate the .env file with custom values" I get it, when the prerequisites are 1) run a server and 2) have Docker installed, but this isn't inspiring confidence that local-first apps will become popular.
      • reilly3000 1y ago
        Self-hosted services and local-first apps are distinct topics. Local-first is about keeping data on clients- orchestrated via a centralized or distributed system. Usually it means installing an app that works offline, and might sync to desktop. Self-hosting is about running servers in owned or rented infrastructure, and that is never a turnkey proposition.
    • stavros 1y ago
      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.
• insane_dreamer 1y ago
  The number of people willing to pay for local-first, self-hosted, or federated apps, and the amounts they're willing to pay, is just not enough compared to vast majority of people who don't care.
• farseer 1y ago
  They were popular until the internet was invented.
• cadamsdotcom 1y ago
  If you spend effort being local-first, you can’t spend that on features or UX. You have a disadvantage vs. competitors who focus solely on the latter.
  • vkou 1y ago
    Is local-first local-only actually harder to build and secure than a four-nines uptime service? I understand that it's less profitable, which is the real reason nobody does it.
    • cadamsdotcom 1y ago
      Building and securing local first is definitely harder than four-nines. Want 99.99% uptime? Easy. Cloudflare, AWS, fly.io, Vercel etc. have poured decades of person-years of engineering into platform reliability and operational excellence so you can get it with a few quick CLI commands.
      • vkou 1y ago
        Just because the infra you built on top of is 99.99% uptime doesn't mean that your application is.
• rvz 1y ago
  "It's open source, build it yourself" - Can't build it for my machine, but will try prebuilt executable. "It works everywhere" - Doesn't run on my GPU, OS combination, will tweak settings for a bit. "Add your API Key here" - Won't do it. "privacy reasons" "You can run it locally then" - I'm really GPU poor and it runs 5 tok/s. #1 Reason? - Lots of friction.
• tracker1 1y ago
  My approach in a similar situation where individual sites may be disconnected from a main hub for potentially days is to basically treat things closer to a CQRS transaction/command model, where all transactions are recorded as such, there's a local "summary" table for current state, but this is overridden on sync with the main hub after transactions are evaluated there.
• grigio 1y ago
  Local first apps are a niche, like offline maps (like tomtom, organics maps)
• TacticalCoder 1y ago
  [dead]
• sroerick 1y ago
  Does anybody remember the architecture that account _unwriter was creating on Bitcoin? You could write a transaction from anywhere using and store data in it. Then you could read it through an API of either a full node or a node that was only subscribed to your unique hash ID. It seemed like a really good architecture to me. He kind of disappeared and most of the work lost
• AlienRobot 1y ago
  I feel like the problem is simply... it should just be a file. And if it were a file, you could sync it with dropbox or OneDrive. And if you can do that, they can't make money selling their own cloud service for their local-first app. More specifically, if you can edit different parts of a same document on different devices, then the document should be split across multiple files that can be synced independently, e.g. a photoshop document where each layer is a separate file and a "main" document simply loads them into a single layer stack. In fact there are too many document types nowadays that are composites of sub-files and are even actually just a zipped folder under the hood. It feels like we should have just been using files all along, or some sort of file-folder hybrid with OS-level support instead of using zipped folders to contain all the files of a single document.
  • MangoToupe 1y ago
    > And if it were a file, you could sync it with dropbox or OneDrive. How do these services resolve conflicts?
    • AlienRobot 1y ago
      They don't. Because what you see in the app is what you loaded from the file. When you save the document you'll know which snapshot you were editing.
  • mweidner 1y ago
    > More specifically, if you can edit different parts of a same document on different devices, then the document should be split across multiple files that can be synced independently A more robust idea is to store a log of changes in files that are synced with Dropbox/OneDrive/etc. To prevent conflict warnings from Dropbox, you'll want each device to write to a separate file. Readers re-assemble the logs into (some) canonical total order, then reduce over that to get the document state. The hard part is re-architecting your app to record all changes, instead of just writing out the current state to disk. However, once you do that, it can form the basis for other features like undo/redo, a view of the file's history, etc. (The changes don't need to be CRDT/OT messages - anything deterministic works, though it's a good idea to make them "rebase-able", i.e., they will still do something reasonable when replayed on top of a collaborator's concurrent changes.)
• flkiwi 1y ago
  "local first" to me translates almost immediately into the following: - What if I don't have that device? - How do I reliably sync between devices? - How do I deal with local storage limits of a device? Silverbullet has become very nearly my illustration of the perfect app, because it has a local, offline feature but syncs back to a server controlled by me. The weakness with SB specifically is any limits on browser storage, though that's less likely an issue for a note-taking tool that is, for me, 99.9% text. Compare Logseq, which used to be browser-based and self-hostable, to their more recent "local-first, app-based" model, with a $15/mo charge to sync and severe usability restrictions in a world where I cannot install arbitrary software at work. So, local-first has for me become synonymous with inconvenience, proprietary, and revenue channel for the dev rather than security and flexibility.
• nitwit005 1y ago
  > When you build a local-first app, you’ve effectively created a distributed system. This is true, but any time there's more than one computer involved it's a distributed system. It doesn't matter if you're "local first" or not. Plenty of apps that resolve everything server side do a terrible job handling conflicts.
• throwmeaway222 1y ago
  The title doesn't match the content well, everyone's responding to the title! The syncing issue is also handled better by making the logical unit that gets changed as small as possible. If you have two people editing a document, instead of locking the document, and wiping out changes from other people, think of it as a series of edits to a paragraph, or smaller a sentence, or even the exact word being changed. If someone has text highlighted, then lock anyone else out from editing it because there is a high chance they're going to erase it or paste over it. Lastly, as AI moves forward, it would be an interesting experiment to start having AI auto-resolve conflicts in the small. (user has been replacing the word taco with burrito, and two users started typing in the same spot TaBurrcoito. Maybe Burrito would win.
  • dpe82 1y ago
    You've essentially described Google Wave style Operational Transformation.
• mrtesthah 1y ago
  Standard notes is a good example of a local-first web app that it super-easy to use without a sign-up.
• sehugg 1y ago
  It doesn't help that app developers don't have a clear idea of how long persistent data will be kept around, as eviction policies are based on complex and often-changing rules/heuristics, despite the availability of navigator.storage APIs.
• DotaFan 1y ago
  Been working on offline apps (Android) for the past couple of years. Syncing is hard. Some takes: - There was never a budget for CRDT's - Conflicts were never our primary focus, instead our focus were business problems - Event-sourced arch + offline first app was quite a fun. Basically I've recorded all the events in sequence in SQLite, queued them up when there was a connection and had network retry policy in place + reverting an event locally if retry failed n-th amount of times.
• montebicyclelo 1y ago
  > 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).
  • hinkley 1y ago
    Editing on phone. Phone dies. Scrounge up tablet, edit again, only rethink some of the work. Hit save. Plug in cellphone. Cellphone turns on. Now what? Depends on the granularity of updates. Did the last changes get sent immediately? Are they gated by a save button? Are they periodically pushed? Some of those don’t need a durable undo, but the rest definitely benefit, and undo has other uses.
  • fireflash38 1y ago
    Or they save as soon as they launch, so no matter what local is newer and you'll lose whatever was on remote.
• 5kyn3t 1y ago
  local first: could actually be a downloadable index.html file, that runs locally only your browser.
• dusted 1y ago
  They used to be really popular, back in the ancient times when I was young and full of excitement for all things compute, almost all software was local-first, and.. only :) But since the entire world economy has turned to purely optimizing for control and profit, there's just no good reason to not screw people over as much and as often as possible, what'll they do ? Switch to someone who won't ? And who would that be ?
  • qzx_pierri 1y ago
    > what'll they do ? Switch to someone who won't ? And who would that be ? FOSS
  • Aurornis 1y ago
    > But since the entire world economy has turned to purely optimizing for control and profit, there's just no good reason to not screw people over as much and as often as possible, what'll they do ? I worked on a somewhat well-known (at the time) product that used on-site hosting. One of our biggest customer complaints was that we didn’t have a cloud hosted option. Many companies didn’t want to self-host. They’d happily pay a premium to not have to host it. I think HN underestimates the demand for cloud hosted solutions. Companies don’t want to deal with self-hosted if they can pay someone else a monthly fee to do it.
    • rkomorn 1y ago
      I can't imagine wanting to self-host something like Jira, GitHub, or some wiki product unless there's a very big financial cost difference that more than offsets my time and hardware investment. Otherwise it seems like I'm just spending time and effort achieving the exact same result.
      • nightfly 1y ago
        I work in an org with 8ish FTEs, a handful of student workers, and like 200 volunteers. Almost every service wants $5 or more per user per month, that's $1,140 per month per service. We selfhost open source solutions for everything we can and sometimes have to write something in-house to meet our needs.
• bongodongobob 1y ago
  They used to be. But if your app is cloud based, that means the businesses you're selling to don't have to have staff and hardware to manage that stuff on prem and can charge a higher subscription fee. For better or worse. The pendulum will swing back, I think, for security reasons. "I don't want company X training AI on our data!" (Whatever that means)
• fennecbutt 1y ago
  Money.
• alkonaut 1y ago
  This whole article reads like normal desktop software or mobile apps are some strange edge case of software, rather than still being a super common way of delivering software. Doing local-first _in a browser_ still feels like taking all the drawbacks of a browser like difficult interop with the rest of the host system and getting only one benefit (ease of distribution).
• gethly 1y ago
  I think this might have something to do with the data being tied to he application itself. In other words no portability/vendor lock-in type of thing.
• HeyLaughingBoy 1y ago
  How will they pay for it? Subscription-based software made a lot of products affordable. $49.95 a month indefinitely is a lot easier for many small businesses to sustain than a lump sum of $1,500 for a software package. Considering how undercapitalized most small businesses are, it's not hard to see why many of them may prefer to rent the software instead of buying it.
• deleted 1y ago
  [deleted]
• earthnail 1y ago
  Unfortunately 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 know about Electricsql) you can also run their offering yourself.
  • kobieps 1y ago
    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/ https://www.inkandswitch.com/essay/local-first/ [2] https://github.com/orbitinghail/sqlsync https://github.com/orbitinghail/sqlsync [3] https://ampliapps.com/sqlite-sync/ https://ampliapps.com/sqlite-sync/ [4] https://github.com/sqliteai/sqlite-sync https://github.com/sqliteai/sqlite-sync
• socalgal2 1y ago
  The article is about syncing an app that runs locally with other instances of the same app on other machines. Ok. What does that have to do with the title? > Why haven't local-first apps become popular? ( I think that the title wants to be is "Why haven't more developers written local-first apps for their syncing solution?" because the the answer to title itself is because users don't care. Users (most) want apps that sync between their phone, their tablet, and their laptop/desktop. Up to some point, they don't care how it happens, just that it does and that they don't have to give it a second thought.
• 1123581321 1y ago
  There is increasing awareness of CRDTs but it’s still unclear to many developers how to integrate them with sql. It seems like a CRDT requires developing a new app, or at least a new data model, rather than benefitting from their existing knowledge. This should change over time; the libraries and documentation keep getting better. I recommend Automerge 3.0’s documentation as an introduction to the concepts and how to bridge with traditional data. https://automerge.org/docs/hello/ https://automerge.org/docs/hello/
  • to11mtm 1y ago
    I think the biggest challenge is brownfield. In greenfield it's easier (so long as you have the grit to build the base pattern); Events get put into tables (TBH this can be optional, but if you're new to it just do it b/c it will make debugging easier,) and if you want a friendly clean 'view' state you have some form of map-reduce replication running on the event set. And yeah you can even remix that idea to work on 'existing' tables but it's gonna be more work and you'll probably want some form of optimistic concurrency check...
• moralestapia 1y ago
  You mean like Microsoft Office?
• b_e_n_t_o_n 1y ago
  Perhaps 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.
  • crazygringo 1y ago
    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.
    • b_e_n_t_o_n 1y ago
      What are some examples of popular apps that do this which aren't web apps, and could feasibly work offline? Every native app I use is local-first. Eg. Photoshop, Blender, Figma, Xcode, Zed, Kitty, Affinity Photo/Designer, Notes, Music, Calendar, Messenger, Maps, Email, etc.
      • crazygringo 1y ago
        I already explained: "exclusively about apps that store their data in the cloud". So Photoshop, Blender, etc. -- these are not apps that store their data in the cloud. They're using filesystems. There's no sync. They're not local-first, they're just local. But the Apple apps -- Notes, Music, Calendar -- they are very much local-first. Their source of truth is in iCloud when you activate that, but they fully work offline as well and then sync once there's a connection. This is completely different from e.g. Photoshop.
      • rbits 1y ago
        Notion is a big one. I tried it out but didn't end up using it because it doesn't work offline. (I know you said not web apps, but it does have a desktop version)
• crazygringo 1y ago
  > Offline-first apps sound like the future: ...no more spinning loaders on flaky connections. Even offline-friendly apps get spinning loaders on flaky connections. Google Docs will be stuck checking to see if a doc has been updated before it loads it, and will only actually open it when I turn on Airplane Mode. Similarly, Spotify will be stuck loading a saved playlist or album because it's trying to load extra information it loads when connected to the internet, and again only Airplane Mode will skip that so it knows it's offline-only. Flaky connections are the bane of existence of apps that work offline, either because apps want to load extra online-only data whenever possible, or simply ensure everything is synced before taking a big action.
• birdfood 1y ago
  I’m building a journaling app primarily for myself but with a view that others might want to use it to. I’ve built it in rails and deployed it. The experience has been great and it’s the first “app” I’ve deployed outside of work. But I haven’t shared it with anyone because I don’t want to be responsible for hosting their data considering the intention of this app. The only “business model” (method of covering costs) I’m interested in is pay to use. I don’t want to do ads or tracking. I think saas is the wrong fit for it. So I’m just this week thinking about making it a macOS / iOS app instead and work out how to do syncing without involving a server.
  • degamad 1y ago
    "Without using a server" is possible, but hard. An alternative is "using a server that the user has", e.g. saving to their iCloud/Dropbox/Google Drive/GitHub/etc. (There used to be old notes applications which would save your notes in an IMAP folder on your email server; almost every user of your app will have email.)
• auggierose 1y ago
  Doing it properly is just hard. There is also this CRDT craze going around, but in the end I think operational transformation is a more general and flexible solution (CRDT is just a special case of operational transformation). I have been looking at the various solutions in this space for a few years now, and in the last two or three months started implementing my own experimental solution as a database using operational transformation. It doesn't help that operational transformation in the literature is somewhat confused (there are not many papers about it that are actually correct), although in the end it is really simple.
• OhMeadhbh 1y ago
  Not really sure what you mean. I still run emacs locally.
• crazygringo 1y ago
  > 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.
  • kobieps 1y ago
    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 https://mattweidner.com/2025/05/21/text-without-crdts.html
    • quotemstr 1y ago
      > Difference from CRDTs The author has made a CRDT. He denies that his algorithm constitutes a CRDT. It's a straightforward merge, not a "fancy algorithm". What specific aspect of a CRDT does this solution not satisfy? The C? The R? The D? The T?
      • justinpombrio 1y ago
        I was going to say that that's not a CRDT because it requires a centralized server (the conflict resolution is "order in which the server received the messages", and clients aren't allowed to share updates with each other, they can only get updates from the server). But now I'm looking at definitions of CRDTs and it's not clear to me whether this is supposed to count or not. Still, every algorithm that's actually labeled a CRDT shares a magical property: if my replica has some changes, and your replica has some changes, our replicas can share their changes with each other and each converge closer to the final state of the document, even if other people have been editing at the same time, and different subsets of their changes have been shared with you or I. That is, you can apply peoples' changes in any order and still get the same result. I don't think it's useful to call anything without that property a CRDT.
• winrid 1y ago
  Time. If it takes more than like 30 seconds to setup the masses will never adopt it.
• bvan 1y ago
  Bring back gold old desktop applications, I say. Apps are for your phone.
• tonymet 1y ago
  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's use. Dirty writes can be handled easily just mark the UI dirty until the write succeeds. My point is that we could easily fix 95% of the offline challenges with no major changes to the app design -- just better habits.
  • themafia 1y ago
    We solved a ton of issues by ensuring Cache-Control was being correctly used on API responses and that our application network layer respected them. The advantage is we can change our mind about cache lifetimes on the server side and no app update is required to start using them.
    • tonymet 1y ago
      I love hearing about easy wins like this. very true on Android and iOS the Data Access Objects will handle content invalidation quite magically when used properly.
  • m463 1y ago
    > 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.
    • tonymet 1y ago
      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)
• dismalaf 1y ago
  Honestly, apps that require the web to actually do the thing you want, but also work offline, are more or less useless. You're basically just faking that it works offline, it doesn't do the thing you want, and it's a PITA for everyone involved. And to try get this right when most of the world has reliable data connections all the time is a colossal waste of effort.
• phkahler 1y ago
  We are both offline with identical copies of the same document. I modify paragraph 3 of 5. You replace the same paragraph with a completely different one. No clocks or CRDTs are going to automatically fix this. The right solution could be my edits, or your new replacement, or some merge, but there isn't any automatic way to do this is there?
• whartung 1y ago
  I dunno. Storing your files on a synced folder (i.e. DropBox or something similar) can handle a lot of heavy lifting. The use case is not simultaneous editing, folks typically aren’t working on things on different systems at the same time. Given that as a basis, next, “save early, save often”. The app is “cloud ignorant”. It just sees a local folder. Most of the syncing systems sync up quite quickly, so even if you save it on your desktop and pick up your phone, it’s probably already synced up. “For free”. Finally your app needs to be cognizant that the file can change behind its back. When it fires up it reloads, or prompts the user, or whatever. Adding in auto save and versioning like Apple does with their apps, and magic happens (though I honestly don’t know how the Apple apps respond if the saved document is changed underneath it). There’s a difference between simultaneous and background changes. No reason to over complicate things for the vast majority of use cases.
• dibrale 1y ago
  I prize local execution for confidentiality and trust reasons, but this mindset seems to put me in a distinct minority. I've just accepted that I will end up having to build my own solutions from time to time. That said, 'local' can mean a number of different things. On-device local, LAN local, intranet local... You get the idea. I chose to go with an approach of: 'assume resources are constrained and build for that'. The result was a local-first agentic system (https://github.com/dibrale/Regions https://github.com/dibrale/Regions) that uses explicit resource sharing and execution patterns to make use of arbitrarily distributed compute. That way, local can be whatever I want it to be, so long as there's an endpoint.
• hamstergene 1y ago
  Sometimes I think the way CRDT research formulates the problem, itself obstructs evolution of local-first. That obsession with Google Docs-like collaborative real-time text editing, a pretty marginal use case, derails the progress from where local-first apps really need it: - offline-enabled, rather than realtime/collaborated - branching/undoing/rebasing, rather than combining edits/messages - help me create conflict-aware user workflows, rather than pursue conflict-free/auto-converging magic - embeddable database that syncs, not algorithms or data types CRDT research gives us `/usr/bin/merge` when local-first apps actually need `/usr/bin/git`. I don't care much how good the merge algorithm is, I need what calls it.
• ChaoPrayaWave 1y ago
  Most people don’t ask whether an app is local first or cloud first. They just want to know: “Can I open it?” and “Will my data be safe?”
• tmpfs 1y ago
  I am totally sold on local first apps. I think the recent enshitification of many services (which is also inevitable for the new wave of AI services) plus the inherent privacy risks with allowing third parties access to our personal data is no longer a trade-off I am willing to make. I set up a little Pi NAS and have moved all my git repositories there thanks to gitea (I still mirror to github for community interaction) and am gradually migrating everything to be stored locally with encrypted cloud backups. I've also been working on a local-first, open-source, eventually consistent password manager[0] (using last write wins) for the last 3 years as I can't think of anything more important that we should have control over. It will be hard for local-first to become more commonplace as SaaS and cloud has become so entrenched but I will keep forging towards a future where we take back ownership of our personal data. [0]: https://saveoursecrets.com/ https://saveoursecrets.com/
• bariumbitmap 1y ago
  Obsidian.md has over a million users in five years, that sounds fairly popular to me. https://www.linkedin.com/pulse/how-obsidians-contrarian-playbook-created-company-we-ehoneah-pharmd-nn53f/ https://www.linkedin.com/pulse/how-obsidians-contrarian-play...
• hnaccountme 1y ago
  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.
  • sbt 1y ago
    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.
  • sebastianz 1y ago
    People want to sync their data, work on and see the same thing on their phone, their laptop and their desktop. This certainly did not "just work" when "we used to have offline everything".
• willtemperley 1y ago
  Finding high quality libraries that are suitable for desktop / mobile distribution is currently very difficult. I'd like to use DuckDB to remotely query Parquet. Unfortunately I can't use it in an iOS app because I'd have to work around the dynamic loading of extensions and bundle OpenSSL to support Httpfs in a static build. I'm building my own library instead. That's just one example. I'd like to use certain LGPL licensed libraries but I can't because the legal risks are too high, as is the cognitive load in dealing with license uncertainty. Neither of these things are an issue for web-apps. I think the economics for local-first software could really work out for businesses that use significant compute. Cloud-compute is not cheap and comes with significant financial tail-risk.
• ciju 1y ago
  We have been building a local-first browser app (PWA) for personal finance, based on double-entry accounting. https://finbodhi.com/ 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.
  • Aldipower 1y ago
    If you go on step further with double-entry accounting you will need to book the "stack" to the "journal" as required by the tax office. I do not see how this should work with you local-first approach, because you cannot really guarantee the correct order. If something is in the "journal" it has to be "canceled", if the action was wrong beforehand. This is an additional booking step and not a "revert" of the previous action. No conflict resolution will help you here. Especially the area of double-entry accounting, is something where I never would choose such an local-first/sync approach. Local-first in the classic desktop app single source of thruth sense, sure, but not this way.
• dhilish 1y ago
  Local first apps are slow when compared to cloud hosted
• dhilish 1y ago
  Local first apps are slow when compared to others
• LAC-Tech 1y ago
  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.
• sbinnee 1y ago
  Answer: internet
• SamLeBarbare 1y ago
  CRDTs and HLCs often feel like over-engineering. In most business/management apps, it’s rare for two people to edit the same piece of data at the exact same time. A simpler approach works surprisingly well: Store atomic mutations locally (Redux-like) in SQLite. Sync those mutations to a central server that merges with last-writer-wins. Handle the few conflicts that do occur through clear ownership rules and some UI/UX design. This makes local-first behave more like Git: clients work offline, push their “commits,” and the server decides the truth. Most of the complexity disappears if the data model is designed with collaboration and ownership in mind.
  • kobieps 1y ago
    Agreed @ overengineering for most use cases. Still, where a simpler approach gets tricky is if you only want to sync a subset of the backend database to any client's SQLite
• gt0 1y ago
  I think developers overestimate how much everyday users care about local-first, or working offline. At home and in the office, we have the Internet, so it's only on the move in places where you phone doesn't work where this matters and most of us probably don't work in those places enough for it to matter. I worked on an app a while back, a synchronising drawing app, and ran into the issues mentioned in the article that synchronising is hard and is solving a problem very few people actually have, the need to work offline. I'm a sort of "desktop app believer" in that I think you tend to get a better UX from native desktop apps than the web, but convincing enough people to believe you or give you money for it is another matter.
  • Mordisquitos 1y ago
    > I think developers overestimate how much everyday users care about local-first, or working offline. And that's because (many) everyday users are not even aware that being online is not essential to perform the functionality they need from their applications. It's not that users don't care that they cannot work offline. It's that they don't even understand that requiring an internet connection is not a technical necessity, but rather an artificial limitation imposed by business interests or incompetence.
• KaiserPro 1y ago
  I think the biggest issue is that if you are putting that effort into syncing, its far nicer for the end user if you manage it for them. If your using the "local" shared storage, then you're on the hook for any failure or setup, so there is a huge amount of debug and reputational damage in store for not very much gain. If you are supporting multi device makers, and a normal audience, (ie people who don't know what CRDTs are) then you doing the hard work is far easier. And thats before we get into ACLs for sharing.
• miki123211 1y ago
  Local-first apps haven't become popular because users want shareable links, cross-device sync and maybe security. For cross-device sync, you need a server. Either you use iCloud (limiting yourself to Apple platforms), host one (which encourages subscriptions and defeats the point of local-first) or ask users to self-host (which is difficult and error-prone). Shareable links also need a server. You can't use iCloud for those, and if you're asking users to self-host, you now need to ensure their server is exposed publicly and has a domain. This adds yet another complication to an already complicated process, not to mention the security implications. Security (where some users are restricted from seeing some of the data and performing some of the actions) requires much more "smarts" in the server, and makes local sync infinitely more complicated. For local-first apps to be viable, we need a lot more primitives first. Apple provides some, but not nearly enough, and only for their own platforms. Nobody else even bothers.
  • chris_money202 1y ago
    Creating a server devices can access on the same network is trivial the only issue you would run into is maybe what port to use and there are discovery processes for this.
    • miki123211 1y ago
      For that to work, you need a device which is online 24/7, always stays on the network, and does not have energy efficiency requirements, which justifiably limit background app activity. The only (consumer) devices that fulfill these requirements are routers and some smart gadgets, like fridges or smart speakers. None of them are easily programmable to a sufficient degree. This still doesn't solve the problem of sharing among users on different networks and accessing your data when you're not home. All these problems are solvable, but they'd require massive coordination among device vendors, and coordination is one of the hardest problems out there.
• Aldipower 1y ago
  Local first web apps - the hybris of the modern web application developer. Sure, for some solutions, local first even makes sense, but for the most, not.
• donatj 1y ago
  I have a note keeping app I have been building for well over a decade at this point. It's never going to release and it's chock full of features only I seem to care about. No one I've shown it to has cared. Recently I went to the grocery store and presented with no signal had to try to recall my grocery list from memory. In all my years using my own app I think this is the first time I'd ever wished it were "local first"
• dajtxx 1y ago
  Such a weird and absurd conversation to be having from the PoV of someone who started using computers a long time ago. Offline first apps 'sound like the future'? I agree they're far better than the trash we have now, but it's not like we can't build them now. We should be building them now. The web was never meant to be an app delivery platform :(
• dajtxx 1y ago
  I think Fusion360 is one of the worst things I've seen. It presents as local but it feels like every mouse click causes a web request to happen. Something that should be local and snappy is just an awful experience.
• Joel_Mckay 1y ago
  The world went mobile, and Faustian software licenses undermined actual ownership. Thus, customers get software companies that are SaaS even when they appear to sell some product. Accordingly, most "Computers" sold today are "information-appliances" with constrained predefined use-cases the dominant OS publishers allow people to use. Few FOSS projects survive contact with such ecosystems, and likewise software App sellers drive platform decay due to shifting priorities that mess with users. This is also why many modern AAA games have online game-play even when it makes no sense to do so... And why we see 147 fart Apps on the App store. =3
• otikik 1y ago
  The article focuses on the technical aspects, but I think the economical ones play a bigger role here. They are misaligned here. What's good for the app user is not necessarily good for the people making the app. I know several companies whole second or third round of investment was very much conditional on them making the pivot from "on premise" to "SASS". On paper, an on-premise app that I can manage on my own infrastructure seems more interesting for me as a consumer. But for the investors of those companies I just mentioned, having a SASS offering is seen as "having a bigger hold on your customers".
• thephyber 1y ago
  CRDTs may solve most of the technical side (albeit with lots of complexity), but how do you solve the “how to explain what happened to the user?” issue? Not all actions are intuitive while offline. For example, if 2 users are both offline and both buy the same last item in the retailer’s inventory. The race condition has to be solved sometime, and the non-winning user will need a communication from customer service apologizing for overselling the item. Those are pretty frustrating conversations when they come from airlines or hotels.
• schickling 1y ago
  Host of localfirst.fm and author of LiveStore here. Your post strongly resonates and I particularly like your conclusion in regards to SQLite. I've been exploring how to build a sync layer around SQLite for the last 5 years as part of LiveStore and settled on embracing event sourcing following a similar architecture to Git but for your application data.
• hulitu 1y ago
  > Why haven't local-first apps become popular? Because FAANG needs your data. Because 5 Eyes needs your data.
• lightningspirit 1y ago
  The balance example should have been explained in more detail — it’s clearly a transactional system where the balance is derived from the sum of transaction log data. CRDTs have nothing to do with it and it is a bad example.