Loro: Reimagine state management with CRDTs

The demo code for Loro looks very easy to use, I love how they infer a CRDT from an example plain JS object. I’ve played with a Zod schema <-> Yjs CRDT translator and found it kinda annoying to maintain. However this looks so easy I worry about apps building with too little thought about long term data modeling. Migrations on CRDTs are challenging, so it’s important to “get it right” at the beginning. I’m curious how this design works with longer term, more complex CRDT apps.

This is amazing. Please share with the big projects which need it the most.. collabora and libreoffice. Also, a product which the world needs badly.. would be a software which would abstract git and present text to lawyers as regular word processor, but in the backend it's git for the win.

This looks really neat. I appreciate that you reference the previous work in this area (by josephg, Ink &amp; Switch, Fugue etc.).<p>I think the roadmap says that WASM is next as a target, and that makes sense for prioritization. Would you also consider Flutter&#x2F;Dart as a target, even if at the level of &quot;we checked once that flutter_rust_bridge can call Loro&quot;?

Can someone explain to me what happens when there is a destructive update on one side while the other side is still relying on some old version?<p>Can this even be reconciliated?<p>Or is it append only?i.e. No delete operation.<p>UIs have delete operations in general.

The performance of this looks really interesting, looking at the demo gif they have on the page.<p>I wonder if this is something that can be used for versioning database columns &#x2F; fields.

We&#x27;ve been using <a href="https:&#x2F;&#x2F;github.com&#x2F;electric-sql&#x2F;electric">https:&#x2F;&#x2F;github.com&#x2F;electric-sql&#x2F;electric</a> for real-time sync for the past month or so and it&#x27;s been great. Rather than make you think about CRDTs explicitly, Electric syncs an in-browser sqlite db (WASM powered) with a central postgres instance. As a developer, you get local-first performance and real-time sync between users. And it&#x27;s actually faster to ship an application without writing any APIs and just using the database directly. Only downside is Electric is immature and we often run into bugs, but as a startup we&#x27;re willing to deal with it in exchange for shipping faster.

I see that the libraries are written in Rust, would this work in a nodejs app as a wasm or as native plugin?

Looks great! We will check it out! And nice to see that you are using React Flow in your example

Curious how this compares with Automerge&#x2F;Automerge-repo [0]. Looks like Automerge is at 2.0.<p>0: <a href="https:&#x2F;&#x2F;automerge.org&#x2F;blog&#x2F;2023&#x2F;11&#x2F;06&#x2F;automerge-repo&#x2F;" rel="nofollow noreferrer">https:&#x2F;&#x2F;automerge.org&#x2F;blog&#x2F;2023&#x2F;11&#x2F;06&#x2F;automerge-repo&#x2F;</a>

How does this compare to Yjs&#x2F;y-crdt?

I couldn&#x27;t find this in the docs, but is it easy &#x2F; transport agnostic to sync two remote instances through the network? What about saving state on the server (so different devices can sync with each other without having to be online at the same time?)

Well it&#x27;s honestly about time. I&#x27;ve tried to build something like this personally with OTs, but it can be pretty brutal with all the fuzzying and N-way merges. I even chose one of rich editors just because it supports OT (then i learned it&#x27;s only in commercial version not even available for small-timers).<p>I like the completeness of the Loro solution: the state, the rich text, the tree. Local-first database approach sounds like a great idea. Wondering how large is the code size overhead for using this though.

great post explaining CRDT and the tool.

Congratulations on the launch! Cannot wait to see Loro in action.