Great write-up! We are considering switching to Yjs for our collab application for D&D game masters (legendkeeper.com) and this assuages many of my concerns in regards to CRDTs. Yjs’ ability to keep a low memory and CPU profile, while also making the offline editing use case way easier to implement, is really awesome.
What an awesome use case!
Great to hear that the article convinced you to switch to Yjs 
Please let me know when you did the switch.
It’ll probably be a month or two but we are excited to tackle it. We’re doing the standard centralized transform method right now, and while it works fine, poor network connectivity really throws a wrench in things, and I don’t see full offline support being feasible using this method without a ton of work and code.
Hi @dmonad
In your blog post, you mainly talked about the space overhead of CRDT and proved that it is practical for a real-time text editor use case.
I just saw another blog Building real-time collaboration applications: OT vs CRDT , talking about preserving intentions. it shows an issue of cursor movement when 2 users working on the same doc.
I wonder if you could share some insights, is this a concern of using CRDT? Thanks.
I’m a bit sad that this blogpost is cited so often. This is an easily solvable problem. It looks like they were looking for an excuse.
Yjs uses relative positions to restore selections after remote changes (the local position must be adjusted when content is inserted before the current cursor position). But you could also do a simple index-transformation as you would do in OT (i.e. when a character was inserted before the current cursor, then increase the cursor position). This is not even a CRDT-specific problem.