Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why haven't local-first apps become popular?

marcobambini.substack.com

Post reply on HN
Print view View original

91–100 of 494 posts

Re: Why haven't local-first apps become popular?

#91

Post by crote »

RajT88 wrote: post #74
setnone wrote: post #62

Just because "personal server" hasn't happened yet in the way personal computer did

That is an interesting thought. How do you make self-hosting appealing to more than weird nerds?

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.

Re: Why haven't local-first apps become popular?

#92

Post by hasanhaja »

VikingCoder wrote: post #49

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.

I've been having fun exploring this actually: https://news.ycombinator.com/item?id=45333494

I've found it to be a fun way to build apps.

Re: Why haven't local-first apps become popular?

#93

Post by robenkleene »

jordanb wrote: post #85
marginalia_nu wrote: post #24

Earlier quoted context omitted.

> 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 wher…

I feel like git set back mainstream acceptance of copy-and-merge workflows possibly forever. The merge workflow is not inherently complicated or convoluted. It's just that git is. When dvcses came out there were three contendors: darcs, mercurial and git. I evaluated all three and found darcs was the most intuitive but it was very slow. Git was a confused mess, and hg was a great compromise between fast and having a…

> The merge workflow is not inherently complicated or convoluted. It's just that git is.

What makes merging in git complicated? And what's better about darcs and mercurial?

(PS Not disagreeing just curious, I've worked in Mercurial and git and personally I've never noticed a difference, but that doesn't mean there isn't one.)

Re: Why haven't local-first apps become popular?

#94

Post by [deleted] »

aleph_minus_one wrote: post #18
gritzko wrote: post #5

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.

> 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]

Re: Why haven't local-first apps become popular?

#95

Post by jjcob »

ktosobcy wrote: post #53

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 item…

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...

Re: Why haven't local-first apps become popular?

#96

Post by zsoltkacsandi »

sylens wrote: post #66

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

There is money in local first apps, businesses are just greedy.

Re: Why haven't local-first apps become popular?

#97

Post by godshatter »

xorvoid wrote: post #23

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…

It's crazy that we live in a time when "pay with money and your data" or "pay with your eyeballs" are the only viable options and "pay with your money without your data" can't even be considered.

Re: Why haven't local-first apps become popular?

#98

Post by echelon »

jakelazaroff wrote: post #80
lordnacho wrote: post #12

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…

I wouldn't call local Excel/Word/etc "local-first". The "-first" part implies that the network is used for secondary functionality, but the apps you're talking about are fully offline. IMO local-first definitionally requires some form of networked multi-device collaboration or sync.

Local-first apps aren't common because teams building web apps are primarily targeting online, database backed, SaaS.

With the exception of messenger clients, Desktop apps are mostly "local-first" from day one.

At the time you're beginning to think about desktop behavior, it's also worth considering whether you should just build native.

Re: Why haven't local-first apps become popular?

#99

Post by robenkleene »

marginalia_nu wrote: post #24
lordnacho wrote: post #12

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…

> 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 wher…

The problem with "human understandable" with respect to resolving syncing conflicts, is that's not an achievable goal for anything that's not text first. E.g., visual and audio content will never fit well into that model.

Re: Why haven't local-first apps become popular?

#100

Post by czx111331 »

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

[2]: https://github.com/loro-dev/loro-todo

Post reply on HN