crdt-benchmarks
automerge
Our great sponsors
crdt-benchmarks | automerge | |
---|---|---|
6 | 32 | |
229 | 13,451 | |
- | 1.8% | |
3.0 | 8.4 | |
8 months ago | about 1 month ago | |
JavaScript | JavaScript | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
crdt-benchmarks
-
Cloudant/IBM back off from FoundationDB based CouchDB rewrite
So yes, a particularly large document is not the norm but it can happen.
JavaScript CRDTs can be quite performant, see the Yjs benchmarks: https://github.com/dmonad/crdt-benchmarks
- Automerge: A JSON-like data structure (a CRDT) that can be modified concurrently
- Automerge: a new foundation for collaboration software [video]
- Show HN: SyncedStore CRDT – build multiplayer collaborative apps for React / Vue
-
5000x Faster CRDTs: An Adventure in Optimization
Cool! It'd be interesting to see those CRDT implementations added to Kevin Jahns' CRDT Benchmarks page[1]. The LogootSplit paper looks interesting. It looks like xray is abandoned, and I'm not sure about teletype. Though teletype's CRDT looks to be entirely implemented in javascript[2]? If the authors are around I'd love to see some benchmarks so we can compare approaches and learn what actually works well.
And I'm not surprised these techniques have been invented before. Realising a tree is an appropriate data structure here is a pretty obvious step if you have a mind for data structures.
To name it, I often find myself feeling defensive when people read my work and respond with a bunch of links to academic papers. Its probably totally unfair and a complete projection from my side, but I hear a voice in my head reword your comment to instead say something awful like: "Cool, but everything you did was done before. Even if they didn't make any of their work practical, usable or good they still published first and you obviously didn't do a good enough literature review if you didn't know that." And I feel an unfair defensiveness arise in me as a result that wants to find excuses to dismiss the work, even if the work might be otherwise interesting.
Its hard to compare their benchmark results because they used synthetic randomized editing traces, which always have different performance profiles than real edits for this stuff. Their own university gathered some great real world data in an earlier study. It would have been much more instructive if that data set was used here. At a glance their RAM usage looks to be about 2 orders of magnitude worse than diamond-types or yjs. And their CPU usage... ?? I can't tell because they have no tables of results. Just some hard to read charts with log scales, so you can't even really eyeball the figures. So its really hard to tell if their work ends up performance-competitive without spending a couple days getting their enterprise style java code running with a better data set. Do you think thats worth doing?
automerge
- Automerge: Collaborative JSON structures in Rust and JavaScript
- Collaborative JSON structures in Rust and JavaScript
- Library: Collaborative JSON structures in Rust and JavaScript
- Conflict-Free Replicated Data Types (CRDT)
- Automerge CRDT – Build local-first software
- Is there a lib or a pattern for synchronizing a complex JSON over the network ?
-
Show HN: Calenday, real-time collaborative calendars for trip planning
Thank you! I actually kind of cheated and didn't have to implement any of that myself because Firebase took care of it. But when I was considering how to build Calenday, those were on my mind. I had read about CRDTs on Figma's blog (https://www.figma.com/blog/how-figmas-multiplayer-technology...) and was considering using something like this to ease the burden on implementation: https://github.com/automerge/automerge
- Automerge。一个类似于JSON的数据结构(一个CRDT),可以被并发修改 (Automerge: A JSON-like data structure (a CRDT) that can be modified concurrently)
- Automerge: A JSON-like data structure (a CRDT) that can be modified concurrently
- A JSON-like data structure (a CRDT) that can be modified concurrently by different users, and merged again automatically.
What are some alternatives?
yjs - Shared data types for building collaborative software
y-websocket - Websocket Connector for Yjs
FluidFramework - Library for building distributed, real-time collaborative web applications
teletype-crdt - String-wise sequence CRDT powering peer-to-peer collaborative editing in Teletype for Atom.
automerge-rs - Rust implementation of automerge
MobX - Simple, scalable state management.
rustpad - Efficient and minimal collaborative code editor, self-hosted, no database required
watoi - Whatsapp Android To iOS Importer
peritext - A CRDT for asynchronous rich-text collaboration, where authors can work independently and then merge their changes.
SyncedStore - SyncedStore CRDT is an easy-to-use library for building live, collaborative applications that sync automatically.
earthstar - A specification and Javascript library for building online tools you can truly call your own.
diamond-types - The world's fastest CRDT. WIP.