There are people looking at how to use them outside of rich text editing, it’s just that the technology was developed/initially applied to text editing.
I’m more excited about the use of CRDTs outside of text editing, there are so many use cases. However there are still some problems to solve with the existing general purpose toolkits such as Yjs and Automerge. Both give you simple data structures and some more complex structures specifically for rich text. For a true conflict free system you need the CRDTs to match your data model exactly so you can never have a invalid state after a merge. This is almost never the case with existing toolkits.
Take Yjs and it’s ProseMirror bindings, Yjs can represent any internal state of a ProseMirror document and merge them. However it does not have an understanding of the specific ProseMirror schema being used, this could limit the valid states possible (a max length on a heading for example). When Yjs merges multiple edits you could end up with an invalid document for your schema, Yjs loads this into ProseMirror which then throws away the invalid data (with the heading example it just deletes the excess text, it may be better to dump it into the next line but should be configurable).
These sorts of problems are “ok” in a text editor but would be much harder to cope with in a database or a 3d cad tool.
Ultimately the general purpose CRDT toolkits need to have more internal types with a wider ability to capture intent. I also think they need to have the ability to understand the schema of the data structure they are tracking and how to handle more complex merges.
The alternative to doing that with a general purpose toolkit is to build your own CRDTs from scratch for your data model. I don’t think many people would go that route though.
Once those sorts of problems have been solved I think we will see their use explode into new areas.
It’s still early days with them but exciting time ahead.
I’m more excited about the use of CRDTs outside of text editing, there are so many use cases. However there are still some problems to solve with the existing general purpose toolkits such as Yjs and Automerge. Both give you simple data structures and some more complex structures specifically for rich text. For a true conflict free system you need the CRDTs to match your data model exactly so you can never have a invalid state after a merge. This is almost never the case with existing toolkits.
Take Yjs and it’s ProseMirror bindings, Yjs can represent any internal state of a ProseMirror document and merge them. However it does not have an understanding of the specific ProseMirror schema being used, this could limit the valid states possible (a max length on a heading for example). When Yjs merges multiple edits you could end up with an invalid document for your schema, Yjs loads this into ProseMirror which then throws away the invalid data (with the heading example it just deletes the excess text, it may be better to dump it into the next line but should be configurable).
These sorts of problems are “ok” in a text editor but would be much harder to cope with in a database or a 3d cad tool.
Ultimately the general purpose CRDT toolkits need to have more internal types with a wider ability to capture intent. I also think they need to have the ability to understand the schema of the data structure they are tracking and how to handle more complex merges.
The alternative to doing that with a general purpose toolkit is to build your own CRDTs from scratch for your data model. I don’t think many people would go that route though.
Once those sorts of problems have been solved I think we will see their use explode into new areas.
It’s still early days with them but exciting time ahead.