Live data from Hacker News

Automerge-Repo: A "batteries-included" toolkit for local-first applications

automerge.org

41–45 of 45 posts

Re: Automerge-Repo: A "batteries-included" toolkit for local-first applications

#41
post #39

Earlier quoted context omitted.

Google Docs is the spiritual successor to Wave, and has been usable for quite some time.

Spiritual predecessor - it was released 3 years before Wave :)

yeah but it didn't gain the features too be a successor to wave until much more recently. point is, the collaborative features of wave exist today :)

Re: Automerge-Repo: A "batteries-included" toolkit for local-first applications

#42
post #16

Earlier quoted context omitted.

still not as fast/efficient as Yjs. there are some benchmarks here from late September’23: https://arxiv.org/abs/2212.02618 disclaimer: i’m a co-author and the paper is focused on a different CRDT framework, but point is that it measures Yjs and automerge side by side

The benchmarks Matt Weidner has been working on are great and outside scrutiny is always welcome, but I should note that I find there's an element of artificiality to them. In particular, testing the performance of the sync system while simulating many users typing into the same document doesn't really measure behaviour we have observed "in the wild". In our research, we've found that editing is usually serial or asy…

> testing the performance of the sync system while simulating many users typing into the same document doesn't really measure behaviour we have observed "in the wild"

We use co-editing far more commonly than serial editing.

Coming from a background of XP (extreme programming, pair programming) and a Pivotal Labs style approach to co-thinking, even for executive work we require everyone in a meeting (whether at conference table or remote) to be in the document being shared, and instead of giving feedback, comment or edit in place.

We care a LOT about how laggy this works, how coherent it remains, or whether it blows up and has to be restarted, or worse, reverted.

If a firm culture "whiteboards" by having one person at the board and everyone else surfing HackerNews, they might not be exercising this. If a firm culture is that whiteboards are a shared activity, everyone gathered around holding their own marker, or even just grabbing it from each other, they might need to exercise CRDTs this way.

Put another way, if you "Share" in conf room with an HDMI cable to a TV, or share in a Teams or Zoom by window sharing, you may not be a candidate.

If you "share" by dropping a link to the document in a chat, and see by the cursors and bubbles who is following along, you are a candidate.

. . .

In "Upwelling" you describe an introverted and solitary creative process, before revealing a sufficient quality update to others.

That is certainly a valid use case for unspooling thoughts from one brain, and if those are the wilds you are observing, makes sense why that's what you'd observe in the wild.

It is not, however, the most productive for inventing solutions to logic puzzles with accuracy and correctness in fewer passes, nor for most any other "group" activity. So maybe your "not what we see in the wild" should be qualified by "but we're actually not looking for live collaboration, we're looking for post drafting merge".

That said, now the choice of the term "auto-merge" is much clearer, advertising your use case right on the tin, if one thinks about it.

So thanks for the upwelling link, repeated here for convenience:

https://inkandswitch.com/upwelling

Re: Automerge-Repo: A "batteries-included" toolkit for local-first applications

#43
post #16

Earlier quoted context omitted.

The benchmarks Matt Weidner has been working on are great and outside scrutiny is always welcome, but I should note that I find there's an element of artificiality to them. In particular, testing the performance of the sync system while simulating many users typing into the same document doesn't really measure behaviour we have observed "in the wild". In our research, we've found that editing is usually serial or asy…

> testing the performance of the sync system while simulating many users typing into the same document doesn't really measure behaviour we have observed "in the wild" We use co-editing far more commonly than serial editing. Coming from a background of XP (extreme programming, pair programming) and a Pivotal Labs style approach to co-thinking, even for executive work we require everyone in a meeting (whether at confer…

Automerge does indeed work with live collaboration, though apparently not currently as efficiently as some other solutions. Everyone working in this space is exploring and looking for solutions that will work for users woth slightly differing priorities. In addition to automerge consider checking out yjs, electricsql, diamond types, replicache, vulcn, or any of the other folks. Hopefully one of them will be just right for you.

Re: Automerge-Repo: A "batteries-included" toolkit for local-first applications

#44
post #40

Would Automerge be a good choice for a non-realtime single-user app that just needs to have reliable offline support? E.g a personal note-taking app where the user will never have any collaborators, but where they expect the app to work fully offline on multiple devices and reliably sync up when they come online.

Yes, it's a great fit for this. You would probably want an internet-accessable sync server with a copy of the repo, so that the data is still available when no peers are online. Bluetooth/uPnP network adapters would be the cherry on top but AFAIK aren't ready yet.

*mDNS not uPnP sorry

Re: Automerge-Repo: A "batteries-included" toolkit for local-first applications

#45
post #23

Earlier quoted context omitted.

Please accept my unreserved apologies, Heather! No offense is intended. I can speak for everyone working on Automerge when I say that we've very much appreciated Matthew's work and have indeed spent quite a lot of time studying and responding to it. We spoke about it in person last week, in fact. As for the use-cases, I do not mean to exclude live collaboration from consideration, just to note that it hasn't been our…

> We simply have slightly different goals in our work, which undoubtedly reflect where our engineering investments lie. I’d love to hear more about this. Do you elaborate anywhere?

I have been writing a video game using automerge-repo for networking & save files. I researched Yjs and Automerge and felt that Yjs is better suited to an ongoing session like a conference call, whereas automerge is better suited for network partitions etc. This fit my use-case best. My opinion might be out-of-date as this area is moving quickly, and there are quite a few options out there now.
Post reply on HN