> Not saying it's not feasible but it's not going to be as fast as making a plain REST call for those use cases that don't require synching.
The whole point of OT is that it lets you fearlessly merge concurrent edits. You can lean on that to rate limit messages to or from the client, if you need to. Because the client can always apply its own edits immediately to its own local model, there's no perceived latency. So, if you design your system right you can batch up changes at any granularity you like (per page, per form, per second, dynamically based on load, whatever). Of course, the tradeoff is that you lean on the OT system more by batching up edits. But it can be made effectively free to transform if the edits modify different parts of the database (using range trees to cull, etc).
But yeah - it is much faster than differential transform. I'm not sure how good diffing algorithms are in practice, but best case they need to scan the entire document. On the other hand OT only requires size & computation proportional to how much was changed. If we're collaboratively editing a 10kb text file, changes will mostly only be a few bytes each. And applying each change using a good rope library is a O(log n) operation.
Of course, all this requires a database which supports OT out of the box whistles innocently