Hacker News Reader

Comment by vouwfietsman | Hacker News Reader

Isn't the direction we're taking with networking and connectivity kind of making this irrelevant? I always feel like local-first is a good idea but I am actually never without internet connection, and building a truly local-first anything is significantly more complicated than the alternative of "always online" for most domains, even if you use various helper libs. A lot of the pages talk about privacy reasons as well, but I don't get that either, if you want privacy then you want encryption, not local-first development.

Finally, in the end what you want to do with your work is to share it, meaning that "doing" your work is for a large part "sharing" your work, which is fundamentally not local-first.

Maybe I am the odd one out here.

View on HN

It is not about being offline. It is more about running queries locally which makes them fast enough that you do not even need a loading spinner [1]. Imagine your whatsapp client would have to do a http request on each UI interaction.

[1] https://rxdb.info/offline-first.html

That sounds exactly like offline capabilities?

The thing I'm missing in this discussion is that there's very few people out there making whatsapp or figma. The vast majority of software development is perfectly served by submitting forms, as mind-numbingly boring as that sounds I think its true.

I feel like the primary challenge of the field of software development is actually to guard simplicity. Local-first becoming a standard is not unlike SPA becoming the standard: it hurts simplicity and digs the hole we are in deeper still.

To help with this, I think any new technology proposed should advertise when it should NOT be used. In this case, I think, this disclaimer should probably say: "most of the time, for most applications, this should not be used".

Think about longevity. Whether I'm writing, drawing, making music, or anything else important to my life, will I still be able to view/edit that data in 20 years? Granted, even with offline-friendly software I may need to port it to new platforms and make sure I back up the data, but at least I have a chance. The data I still have from 20 years ago is far more precious to me than I thought it would be back then. Data that can only be accessed through an external party is ephemeral and it will inevitably disappear one day.

You are right to talk about the data first and foremost. 20 year old software is very rarely useful (yes there are exceptions) but the data is often just as valuable as before or even more so.

That is why I much prefer a web app that lets me download my data in an open and well documented format to a desktop app that locks my data into some obscure proprietary format or even into a particular device.

> I am actually never without internet connection

You are part of a very small minority. The fact is, the majority of the world can't always be online, and so can't be properly served by always-online applications.

For me, getting on a train in the UK is enough to break almost every app. I’m “technically” connected but signal can be spotty at times, with massive latency spikes and packet drops, and any kind of interaction that depends on the network will stall, which is incredibly frustrating.

Every time I’m in that situation (or get on a plane), I’m reminded of the value of local-first software.

Similar experience in Germany – even inside metropolitan areas inhabited by millions.

Saying that offline, local-first apps aren't relevant because "almost everyone is always online" rings similar to saying accessibility isn't relevant because almost everyone can use their eyes.

As for sharing, that's very much application dependent: personal data could benefit from being shared across a user's device, but not with third parties.

> Saying that offline, local-first apps aren't relevant because "almost everyone is always online" rings similar to saying accessibility isn't relevant because almost everyone can use their eyes.

It’s true, and that “almost” is smaller than you think! There’s a concept called temporary disability which shifts the meaning of “disability” from “some permanent crippling condition” to “unable to do X thing in a given moment”.[1]

For example, one place I regularly go without reliable Internet is… the subway! There’s no signal between stations, so if I need access to something I have to make sure it’s downloaded first.

My grocery store also has a basement with no cell reception. Imagine if the notes app with my grocery list required an Internet connection!

[1] https://mas.to/@carnage4life/109840772570956275

Local-first goes beyond privacy and offline, but nevertheless I think it serves those goals better in fairly obvious ways.

I'm a programmer and artist that works with various non local-first tools (ranging from project management/task collaboration, diagramming, programming--iterating and generating code, etc) and the thing I want more than anything is the fast, tightly integrated experience you get from desktop apps. (The web tech stack is all oriented around consumer-first and not producer-first.)

We need a streamlined tech stack for desktop-first applications. Which probably involves a p2p (*ish) connection and sharing mechanism (nostr looks interesting for this), CRDTs or other patterns, and -- why is this so friggin hard -- tools, frameworks and libraries for cross-platform desktop apps (and don't say you can't retain OS-specific touchpoints when doing this).

Why would you need CRDT for this traditional OT, this always turns into some weird political debate about decentralisations.

The complexity has not necessarily something to do with consensus algo, where CRDT are not best in class, but what if your creative app is using some compute shader for some visual effect? This is not possible without WebGPU, and then still someone has to do the work of porting all of this.

Why is not wanting every action one takes on the web getting collected, analyzed and sold considered a "weird political debate"?

100% agree. I want a web where using web apps is private by default. Been working on an attempt to move towards this: https://peergos.org/posts/a-better-web

What kind of tight integrated experience are you imagining? Is it integration with 3rd party API services? Or with other desktop apps on the same local computer? Or something else?

>building a truly local-first anything is significantly more complicated than the alternative of "always online"

Wow. That is so incredibly wrong. People have been building local-first software twice as long as the internet has even been publicly accessible at all.

The tools to build local native apps, the UI for them, and the libraries that they can use, are all still decades ahead of the web-first tools.

I say this as someone who has spent the last 15 years building web apps. We haven't even reached parity with 1995-era desktop apps yet. We're only barely beginning to approach that level of usability and functionality now. And with radically more complexity to do so. (And worse performance.)

Building native desktop software without having any dependence on being online all the time and dependence on having high bandwidth and dependence on a good signal is worlds simpler than developing software that depends on all that extra stuff. All that stuff that is out of your control.

It is more complicated. If you can accept an always online / always connected model then you can guarantee more things because there is only one source of truth (the server). The reason to care about local first is that even today, it’s hard to guarantee a server will always be connected and that model has some privacy and scalability challenges.

I'm without internet connection multiple times a week on average because mobile networks are far from flawless (I live in that very rural place where you'd expect to not have regular connectivity called London). I don't necessarily care so much about "true" local first as 1) something where at least some care has been taken to ensure it can keep working while offline, 2) with respect to privacy, I halfway agree with you, but bigger than privacy to me is portability, for example if it turns out I can't trust the current provider. But defaulting to not shipping my data to a server somewhere is a good way of increasing trust. That said, I want encryption too.

With waves of climate change disasters sweeping at an increasing rate across the world, and resulting wars being almost inevitable in the next few decades, you are unlikely to have always-on internet for the entirety of your life. My region (first world, in a wealthy nation) has had its infrastructure (roads and comms alike) largely destroyed twice in the last year or so. As we're rich, it gets built back, but that takes time. I've been stung enough from weeks'-long outages and periods of isolation to never again completely rely on an internet connection. I do use software that requires a connection, but not for anything critical.

> building a truly local-first anything is significantly more complicated than the alternative of "always online" for most domains

It is more complicated. It works best when the user has a distinct data bucket that is exclusively theirs. A note taking app. Personal finance. But they may have multiple devices so syncing is desirable.

This use case is reasonably common and turns out to be relatively simple to do.

If you have shared data between users. If you have a significant amount of data that just requires being online to interact with the system. Then it has pretty minimal benefits over just centralizing the data and it should be avoided to minimize complexity.

>But they may have multiple devices so syncing is desirable.

USB cables or thumbdrives make that a snap, and you don't have to rely on some flaky third-party system or a network connection. It's all 100% under your control 100% of the time.

Really, social interactive shared things are the only things where it ever makes sense to be online-first. For everything else, native is way better in every possible way. Speed, security, ability to still access it in the future, etc.

It's good to have online backups in case your house burns down. But that's still second-tier to having local backups.

I would hate and never use an utility app that requires me to constantly physically connect my devices in order to keep data in sync.

I agree with this sentiment. Our networks are only getting faster.

Keeping 100% of the application state in exactly one place can eliminate entire universes of problems.

If you are building an app that doesn't actually need to talk to outside things, then sure. Go 100% client-side.

The dragon is having 1 foot in each swimming pool. 50/50 state spread evenly across client & server.

How about having the state 100% on server AND on client? No dragons, no problems.

Keeping them in sync is the dragon

CRDT is the dragon slayer

It's the sword that we needed! But it doesn't take us all the way. There are semantic conflicts that are difficult for CRDTs to solve alone.

What are the semantic conflicts you mean here?

As far as I can tell, CRDTs are the correct solution for syncing state between parties.

Merge conflicts that must be resolved by the user (i.e. when there is no logical way to determine the priority of two offline changes) are still an application specific problem, even with CRDTs. You can build structures that allow storing conflict resolutions in CRDTs, but getting them right is still like half the problem to solve.

Yes, sometimes it is hard to come up with the merge strategy that preserves user intent. I think the big one is rich text, where Peritext[0] looks like a good direction.

[0]: https://www.inkandswitch.com/peritext/

I have lack of imagination to think what kind of conflicts those would be, would you have examples?

In my experience there’s always a logical way to solve conflicts. And CRDTs can have any kind of conflict resolution algorithm, so it’s customizable per application. “Storing conflict resolutions”, eg. “a merge operation”, is not needed and unnecessarily complicates any CRDT.

This is the correct answer :)

How do you prevent sync issues?

One local DB/store for each app. Who is the correct sync?

Or is it first in first out?

CRDTs is how sync issues become non-issues. The “correct sync” is deterministically determined by the CRDT conflict resolution algorithm. There can be multiple DBs/stores per app or per user or per whatever makes sense. One big global DB/store broken down to millions of DBs/stores.

Then you get to deal with conflict resolution, which is a rare dragon that is kind of confusing and sometimes has to ask the user which state they'd like to keep.

Not if you assume the server is always right. Which is suitable for the majority of cases.

Another possibility is to assume the user is the authority and is always right. For example, if I post a tweet to my feed, I’m (or should be) the authority and always right.

It does, but I think we no longer live in that kind of environment. Distributed is the norm, and trying to shoehorn it into a mental model where everything is all in the same place adds a kind of accidental complexity to our underlying stack for simplicity at the very top.

As an aside, with the future as a (potential) interplanetary species, networks can't beat the speed of light, so we'll have to figure this out then!

Been involved in projects like software adoption in remote aid posts in Papua New Guinea that don't even have roads, and Agtech apps in deep rural Australia.

Even with Starlink there will still be places that stuff needs to work offline.

It’s not only about being able to operate disconnected for long periods it’s also about handling network partitions and being able to achieve consensus without a single source node.

If you travel, you'll constantly experience no or degraded internet access. Airports, trains, hotel Wi-Fi, rural areas, etc.

It heavily influenced how I work and which tools I use.

Many people are not online all the time.

Many people don’t want to share all of their data and would like to keep some local.

Reply on news.ycombinator.com