The basic problem with OT (and current "real-time" collaborative editing approaches) is that they can only achieve eventual consistency.<p>While this sounds great, eventual consistency DOES NOT mean semantic consistency. This rules it out for many applications where semantic correctness is important.<p>Even for simple text documents you can get eventually correct but semantically incorrect results.<p>For example, consider the sentence<p>"The car run well"<p>This has an obvious grammatical error.<p>Now imagine two collaborative editors.<p>Editor 1: Fixes this to<p>"The car runs well"<p>Editor 2: Fixes this to<p>"The car will run well"<p>Depending on the specific ordering of character inserts and deletes this could easily converge to<p>"The car will runs well"<p>Obviously this statement is both grammatically incorrect as well as semantically ambiguous. (However, both editors see the same result and it is hence eventually consistent). Worse, OT collaborative editing will silently do this and carry on.<p>Now, for non-critical text where errors like this are ok, this may not be a big problem. But imagine contracts or white papers, or trying to use this on something like a spreadsheet where semantic correctness is critical and one can see why the current scope of collaborative "real-time" editing is very limited.<p>In general current "real-time" editing approaches like OT are outright dangerous.
Great! I like the format of the post a lot: demo, code example and super clear explanation all combined in a good starting point on the subject.<p>(You could also have cited Etherpad as a common implementation in addition to Docs. Etherpad was a direct predecessor to character by character OT in Docs —the team was acquhired— and it is still widely used by many organizations. But then there is so many examples and libs, I understand that you wanted to just give context!)
Wow! Front-end only is actually a great advantage for me. I actually tried to modify [ShareDB] to be front-end only[1]. (ShareDB uses WebSockets or any other full duplex stream; it's a great reference if you want to implement true client/server.)<p>I guess my use case is quite unique: [Todo.taskpaper] needs to sync multiple "views" of a single document in the same web app. Right now it uses very naive syncing; I'm going to try to upgrade it to blue-ot.js.<p>[ShareDB]: <a href="https://github.com/share/sharedb" rel="nofollow">https://github.com/share/sharedb</a><p>[1]: <a href="http://stackoverflow.com/q/40616650/117030" rel="nofollow">http://stackoverflow.com/q/40616650/117030</a><p>[Todo.taskpaper]: <a href="https://todo-taskpaper.leftium.com" rel="nofollow">https://todo-taskpaper.leftium.com</a>
This is cool! I've been working on something similar in Go, but I haven't spent much time on it recently. Is this a purely front-end application, or is there a server associated with it?