Your web app but good: Aaron Boodman (Local-First Conf)

Hi Joseph, There is a lot of debate about this in the community. People like pvh, adam wiggins, and johannes have all said they consider Replicache and Zero part of the local-first movement [1] and that they would be sad if we and other things like us weren't in it. I was even invited to speak at local-first conf, where we announced Zero last May. [2] I think in practice delivering on the local-first ideals is ultimately up to the app developer not the library. Like in practice every yjs app talks to its server over some bespoke protocol and is loaded over a URL. If that server goes away your yjs app is a brick. No less a brick than if your zero server goes away. Similarly although everyone likes to claim Linear as a local-first app, if the Linear server goes away your Linear app is a brick. Yeah you can export the data from IDB or whatever but you could do the same for Zero or any of these systems. That all said, for our part, we have recently tried to avoid claiming Zero and Replicache as local-first on our own sites to avoid this controversy [3]. 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. So I don't really care too much if it qualifies as local-first (except insofar as I like hanging out with the local-first folks and would be sad to not get invited to the parties). I forgot to mention this to Nate when he showed me these m

Zero (zerosync.dev) uses transactional conflict resolution, which is what our prior product Replicache and Reflect both used. It is very similar to what multiplayer games have done for decades. It is described here: [link] It works really well and we and our customers have found it to be quite general. It allows you to run an arbitrary transaction on the sever side to decide what to do in case of conflicts. It is the software equivalent of git asking the user what to do. Zero asks your code what to do. But it asks it in the form of the question "please run the function named x with these inputs on the current backend db state". Which is a much more ergonomic way to ask it than "please do a 3-way merge between these three states". Conflict resolution is not the reason why there has not been a general-purpose sync engine. None of our customers have ~ever complained about conflict resolution. The reason there has not been a general-purpose sync engine is actually on the read side: - Previous sync engines really want you to sync all data. This is impractical for most apps. - Previous sync engines do not have practical approaches to permissions. These problems are being solved in next generation of sync engines. For more on this, I talk about it some here: [this video]