> I think we're building something really valuable that a lot of people are excited about. And I think we're making the right tradeoffs for the majority of software that most people use every day.
I agree! I wanted live server sync like this for years. And I built ShareDB years ago along those lines, many years before the term “local first” came into being.
But I see a pretty big difference between “server based app with sync” and “local first software”, party invitations aside. I wish we made a term for server based sync - I think it’s marvellous, and it’s important for all sorts of use cases. I think it’s ridiculous modern databases don’t have live queries built in as a standard part of sql. You’re doing great work here.
But all that said, I personally actively avoid calling sharedb local first because I don’t think it is. One big difference is authentication - who has permission to edit the database? And when? With sharedb (and I assume zero), it’s possible to add logic on the server to reject edits. It’s not possible to do this in the same way when clients can write to Yjs or automerge, connect to one another directly and broadcast their changes without the server in the loop.
That’s a pretty big difference - at least to me. I can’t speak for pvh, since I don’t get invited to those parties. But I want language to differentiate those two kinds of software. I’ve been writing software that straddles that line for over a decade, and that difference of how authoritative the root server is really important. It really changes a lot of things about how we build software.
I think the situation is like if we didn’t have a good term for client-server encryption so everyone just calls their software E2E encrypted even when it’s just using tls and encrypting data in transit.
I don’t think you should stop going to local first events. But I don’t think being invited to super cool parties tells us anything about your code. That makes you, personally, a member of a community. But the local first software question is, as I see it, a technical distinction. Not a social one.
The zerosync website says this:
> But where Zero really shines is “local-first” style applications like Linear and Superhuman.
Personally, I find that a pretty confusing claim. “Seamless online / offline support”? Sure. Rad as f? Absolutely. Local first? Eeehhh. It looks like a modern sharedb with a Postgres backend, better caching, maybe cleaner client side api and no collaborative editing. Definitely cool, but very, very different how local first software is described in the paper. That or I should start claiming sharedb is local first too, and muddy the waters forever. Gmail offline mode? Local first everyone. You're welcome!
As for websites that support offline data but can’t be loaded without a server, why not? App manifests can solve a lot of that. (Though nobody ever tries actually opening websites when they’re offline, so maybe there’s no point setting it up).
Personally, I’ve never heard of Linear. And I’ve never heard “everyone say” it’s local first. But if it’s a brick without the server, sorry, but I think everyone is wrong.
>> But where Zero really shines is “local-first” style applications like Linear and Superhuman.
It is a difficult thing to communicate since the vast majority of people interested in Zero are coming looking for "local-first". And for better or worse what they have in mind is Linear (it's a very popular and widely respected bug tracker that calls itself local-first) not Apple Notes.
I'm officially (waves hands in proclamation) inviting you to the next local-first conf. It's crazy fun. Tons of smart people working on all things sync.
I don’t get it. Why would you call something that needs a server to work local-first :?
My app that stores its state on my local disk with optional sync to a server is local-first. If the server goes away, the app continues working flawlessly, you just won’t be able to sync any more (unless you host your own server).
I find it hard to imagine people think of Linear when they hear local first.
I think there are two valid interpretations of the words “local-first”.
1) The outcome of all interactions can be seen locally first, but are sent to a server too. Optimistic updates on steroids, largely done to make software seem faster. Linear is the notable example.
2) The app is built so that it’s fully functional and useful without any kind of internet connectivity. But if network _is_ available, there are some augmented capabilities. Think note-taking apps like the one built into MacOS and iOS, or Bear
Right. And I think only (2) should count as local first software. And only (2) fits the definition provided by the local first software paper.
Option (1) is a legitimately useful way to build software. I wish more apps considered offline support. But I don't think "it works offline" is enough to make something count as local first software. For example, I don't consider Dropbox to be a "local first" tool.
I'm worried the "local first" term will be watered down by projects like this. That distinction matters. At least to me.
Exactly this, "local-first" here mostly is a marketing term rather than a technical one.
I'll tell you a funny(real) story. where i live there is a popular valley, well let's call it X-Valley. the name is very popular and gets a lot of tourism to the valley, so much so that all the surrounding valleys now advertise them as X-Valleys on the internet. and they get a lot of (re: majority of) their tourism business from doing that.
Second is the people's understanding of the term "local-first", I doubt many truly understand the real one from ink&switch. what a good chunk of them are really looking for is offline-first or even optimistic-ui based sync system.
Hah I'll watch the video when I have a chance. Thanks for the invite - I'll have to wait and see when the time & place are announced. Maybe I'll see you there!
I agree! I wanted live server sync like this for years. And I built ShareDB years ago along those lines, many years before the term “local first” came into being.
But I see a pretty big difference between “server based app with sync” and “local first software”, party invitations aside. I wish we made a term for server based sync - I think it’s marvellous, and it’s important for all sorts of use cases. I think it’s ridiculous modern databases don’t have live queries built in as a standard part of sql. You’re doing great work here.
But all that said, I personally actively avoid calling sharedb local first because I don’t think it is. One big difference is authentication - who has permission to edit the database? And when? With sharedb (and I assume zero), it’s possible to add logic on the server to reject edits. It’s not possible to do this in the same way when clients can write to Yjs or automerge, connect to one another directly and broadcast their changes without the server in the loop.
That’s a pretty big difference - at least to me. I can’t speak for pvh, since I don’t get invited to those parties. But I want language to differentiate those two kinds of software. I’ve been writing software that straddles that line for over a decade, and that difference of how authoritative the root server is really important. It really changes a lot of things about how we build software.
I think the situation is like if we didn’t have a good term for client-server encryption so everyone just calls their software E2E encrypted even when it’s just using tls and encrypting data in transit.
I don’t think you should stop going to local first events. But I don’t think being invited to super cool parties tells us anything about your code. That makes you, personally, a member of a community. But the local first software question is, as I see it, a technical distinction. Not a social one.
The zerosync website says this:
> But where Zero really shines is “local-first” style applications like Linear and Superhuman.
Personally, I find that a pretty confusing claim. “Seamless online / offline support”? Sure. Rad as f? Absolutely. Local first? Eeehhh. It looks like a modern sharedb with a Postgres backend, better caching, maybe cleaner client side api and no collaborative editing. Definitely cool, but very, very different how local first software is described in the paper. That or I should start claiming sharedb is local first too, and muddy the waters forever. Gmail offline mode? Local first everyone. You're welcome!
As for websites that support offline data but can’t be loaded without a server, why not? App manifests can solve a lot of that. (Though nobody ever tries actually opening websites when they’re offline, so maybe there’s no point setting it up).
Personally, I’ve never heard of Linear. And I’ve never heard “everyone say” it’s local first. But if it’s a brick without the server, sorry, but I think everyone is wrong.