I'm not sure what to add. I definitely agree that CRDT is viable for collaborative editing, I'm just saying people need to be aware of the issues.
Regarding position and undo, these are problems that can also be solved just fine using OT techniques, and are (imho) simpler when there is a central authority that can order all revisions into a globally consistent sequence.
I think it's inevitable that people are going to misunderstand arguments, given the complexity of the underlying space and the paucity of good learning resources. So thanks for your writeup, it adds to the discussion.
Just to add my 2c, having written sharejs and sharedb and working on and off on OT systems for the past 10 years or so:
After playing with a simple implementation of Martin Kleppmann’s newest automerge work, I was wrong to doubt CRDTs. I’m seeing about 6M ops / second in a prototype text engine in rust. I have much more to say on this - probably a blog post more to say. But I think CRDTs are the future for many workloads, and I have a strong sense of despair seeing how much time I’ve wasted investing in approaches which won’t feature strongly in the future.
> I have a strong sense of despair seeing how much time I’ve wasted investing in approaches which won’t feature strongly in the future.
Your comment makes me sad on several levels..
Firstly, ShareJS and OT types was the first open framework to build collaborative applications on the web. Your work inspired me to work on shared editing - I just wanted it to work over WebRTC.
Until 2015, JavaScript engines implemented different garbage collection approaches that wouldn't allow efficient CRDT implementations (as they need to handle millions of objects).
The idea of distributed applications on the web just popped up a couple of years ago. WebRTC didn't even exist when you started ShareJS. Even Websockets were still a bit experimental. OT was the right technology at the time.
Lastly, I'd love for you to try out Yjs. The current JavaScript implementation handles 2.5 million operations / second. A Rust/C implementation would surely handle more than that as it is not limited by automatic garbage collection.
You can compare Automerge's current performance branch with Yjs' current implementation in [1]. To be fair, their implementation is not finished. If I understood correctly, they want to load the compressed format directly into memory. I played with this idea a few years ago and represented the Yjs model in an ArrayBuffer. This approach will improve load-time, but the performance will be intolerable in other aspects (e.g. when applying document updates, transforming the document to a String/JSON, or when computing diffs). The performance of Yjs is the result of more than five years research. I still have a couple of ideas to improve performance significantly. Although, my article clearly shows that it is definitely good enough now.
Regarding position and undo, these are problems that can also be solved just fine using OT techniques, and are (imho) simpler when there is a central authority that can order all revisions into a globally consistent sequence.
I think it's inevitable that people are going to misunderstand arguments, given the complexity of the underlying space and the paucity of good learning resources. So thanks for your writeup, it adds to the discussion.