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

421–430 of 494 posts

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

#421

Post by arccy »

tylerchilds wrote: post #337
Aurornis wrote: post #311

Earlier quoted context omitted.

Almost every time I see CRDTs mentioned it’s used as a magic device that makes conflicts disappear. The details, of course, are not mentioned. Technically an algorithm that lets the last writer win is a CRDT because there is no conflict. Making a true system that automatically merges data while respecting user intent and expectations can be an extremely hard problem for anything complex like text. Another problem is…

You can resolve it with an algorithm, like so - prefer seniority - prefer pay scale - prefer alphabetical - roll dice That’s how a business would probably do it since the first two alone align with how the business already values their Human Resources, which would translate to “the objects that the Human Resources compete for”

and the interns get the blame for what they can't book why rooms, but for the people managing them it's just so easy.

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

#422

Post by Mordisquitos »

gt0 wrote: post #390

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

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

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

#423

Post by palata »

rkomorn wrote: post #316
Aurornis wrote: post #313

Earlier quoted context omitted.

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

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.

Have you ever checked the cost of GitHub runners? Quickly offsets self-hosting ones.

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

#424

Post by internet_points »

kelvinjps wrote: post #176

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: jus…

This is more or less what I do too. I sync my whole /storage/emulated/0 on Android, which gives me Photos and Downloads etc. to my laptop. I also put Syncthing on an always-on tiny computer at home so if either laptop or phone is off, I can still sync from the other one (so that little home computer is my "cloud", didn't require anything more than plugging in eth and running syncthing).

Syncthing uses "disovery servers" so no need for public IP's or wireguard or anything like that (you can set up your own if you don't trust syncthing https://docs.syncthing.net/users/stdiscosrv.html but they're only used for that discovery part, which is one of the main hurdles when you start thinking about peer-to-peer systems).

(However, I use Fastmail's calendar, for handling invites and since it keeps my subscriptions up-to-date. Considering the move from bitwarden to keepassxc.)

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

#425

Post by rkomorn »

palata wrote: post #423
rkomorn wrote: post #316

Earlier quoted context omitted.

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.

Have you ever checked the cost of GitHub runners? Quickly offsets self-hosting ones.

Runners? Yes. There are definitely some compute/resource heavy things that are more efficient to self host. Until you run out of capacity and getting more capacity involves something like having go buy more hardware and data center space (which I've had to do, though not for CI reasons specifically).

GPU-heavy tasks were also heavily in favor of buying hardware and self-hosting at the time I was making purchasing decisions at my job.

Not everything falls in that bucket and the examples in my comment don't (GitHub isn't just runners).

Edit: I'll also add a question: what part of "unless there's a very big financial cost difference that more than offsets my time and hardware investment" did you think would not cover "have you checked the cost of GitHub runners?"

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

#427

Post by jon-wood »

throwaway4226 wrote: post #418
account42 wrote: post #391

Earlier quoted context omitted.

> Or is there a global lock on any transaction affecting a meeting room, so only one goes through? (Feels like it doesn’t scale) Why wouldn't it scale? How many meetings are booked per second in your organization???

I think the potential for abuse is high. With a locking system, someone could (and probably would) click (manually or with a script) on a time slot to "reserve" a room just in case they needed it.

These are physical meeting rooms within a company. The resolution to this sort of abuse doesn't need to be automated, first it's a person in the facilities team having a quiet chat with the person doing that and asking them not to, eventually it gets escalated through various managers until it's a very final chat with HR before being asked to leave the building and not come back.

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

#428

Post by robenkleene »

MathMonkeyMan wrote: post #301
robenkleene wrote: post #115

Earlier quoted context omitted.

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

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

Not sure I'm following, what's the importance of the term "app"?

(And yes, they're all local first on mobile as well.)

(Also Notes and Photos were mobile apps on the iPhone first [not that it really matters, just FYI].)

Apple continues to release new apps under this model today (i.e., local first), e.g., https://en.wikipedia.org/wiki/Freeform_(Apple). In my mind, the evidence just points to Apple thinking local-first is the best approach for the software on their devices.

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

#429

Post by Aldipower »

0xffff2 wrote: post #133

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.

And the example #1 isn't even better. Maybe, I am not smart enough, but when the physical clock of user B is _way_ off in the wrong direction, you still get the wrong ordering. Example 1 assumes that the users clocks are going more or less correct, which is sometimes just not the case.

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

#430

Post by account42 »

WorldMaker wrote: post #171
robenkleene wrote: post #93

Earlier quoted context omitted.

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

Darcs is a special case because it coevolved a predecessor/fork/alternative to CRDTs [0] (called "Patch Theory"). Darcs was slow because darcs supported a lot of auto-merging operations git or mercurial can't because they don't have the data structures for it. Darcs had a lot of smarts in its patch-oriented data structures, but sadly a lot of those smarts in worst cases (which were too common) led to exponential blow…

At the end of the day all of these have the user start with state A turn that into state B and then commit that. How the that operation is stored internally (as a snapshot of the state or as a patch generated at commit time) is really irrelevant to the options that are available for resolving conflicts at merge time.

Auto-merging code is also a double-edged sword - just because you can merge something at the VCS-level does not mean that the result is sensible at the format (programming language) or conceptual (user expectation) levels.

Post reply on HN