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 re…
Why haven't local-first apps become popular?
31–40 of 494 posts
Re: Why haven't local-first apps become popular?
#32Earlier quoted context omitted.
Ahhh Lotus Notes... in many ways ahead of its time, timeless and horribly outdated at the same time.
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.
Re: Why haven't local-first apps become popular?
#33> 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.
'Offline-first' is trying to combine the benefits of both approaches.
Re: Why haven't local-first apps become popular?
#34It 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.
Re: Why haven't local-first apps become popular?
#35I 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…
Look at single player video games, cannot get more ideal for local-first. Still you need a launcher and internet connection.
Re: Why haven't local-first apps become popular?
#36Sync problems are harder than just 'use a CRDT'.
What counts as 'consistent' depends on the domain and the exact thing that is being modelled.
Re: Why haven't local-first apps become popular?
#37Technical 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 so…
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.
Re: Why haven't local-first apps become popular?
#38The 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 A…