Live data from Hacker News

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

automerge.org

1–10 of 45 posts

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

#3

Super excited to see Automerge getting this high-level API out. Been following since before 1.0 and I can't wait to play around with the latest incarnation! Congrats to the Automerge team.

Thanks, Scott. This API should make it much, much easier for folks to build with Automerge and kind of just encapsulates everything we've been doing in-house over the last few years.

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

#5
This is super powerful, been playing around with the previous releases for the past few days. It works really well, but still needs a few dx tweaks to make it performant for large applications. You have to watch the callbacks yourself to update slices of state and unless your app is small enough that the whole thing can re-render every update.

That being said, I love everything automerge is doing and hope this pace will keep up!

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

#6
Cool stuff!

What do you suggest is the sweet spot for document size and "hotness"? Your cookbook [0] says "We suspect that an Automerge document is best suited to being a unit of collaboration between two people or a small group." Does that mean tens of kilobytes? Hundreds? More? And how much concurrent contention is viable? And is the "atom of contention" the document as a whole, or do you have any plans for merging of sub-parts?

Also, do you have support for juggling multiple transports, either concurrently or back-to-back? In particular, I'm thinking about synchronizing via the cloud when connected, and falling back to peer-to-peer when offline. In that peer-to-peer case, how many peers can I have, and can my peer network behave as a mesh, or must it stick together to some degree?

And finally, it looks like your tutorial [1] doesn't actually exist! You refer to it in a blog post [2], but it's a dead link.

[0] https://automerge.org/docs/cookbook/modeling-data/

[1] https://automerge.org/docs/tutorial/introduction/

[2] https://automerge.org/blog/automerge-2/

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

#7
If you are interested in this, check out the video from StrangeLoop 2023:

https://www.youtube.com/watch?v=Mr0a5KyD6BU

Also, check out the unconf for localfirst that happened right after 2023:

https://github.com/LoFiUnconf/stlouis2023

Ink & Switch is doing such interesting stuff. Their after party at StrangeLoop was so cool.

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

#9
post #4

Last time I looked into CRDT, automerge was not as fast/efficient as yjs, but the team was actively improving the algorithm. Is there any benchmark to show the progress.

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

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

#10
post #7

If you are interested in this, check out the video from StrangeLoop 2023: https://www.youtube.com/watch?v=Mr0a5KyD6BU Also, check out the unconf for localfirst that happened right after 2023: https://github.com/LoFiUnconf/stlouis2023 Ink & Switch is doing such interesting stuff. Their after party at StrangeLoop was so cool.

It's too bad the unconf was full, I didn't get in. Hopefully they do it again.
Post reply on HN