Live data from Hacker News

Open source collaborative text editors

juretriglav.si

81–90 of 167 posts

Re: Open source collaborative text editors

#81
A CKEditor 5 team member here. Thanks a lot for such an in-depth analysis, the article is a great read and we truly appreciate being a contender there.

As for the existing implementations of CKEditor 5 with real-time collaboration, I'm afraid since the collaborative editor is usually a component of a larger platform (publishing, e-learning, CMS, intranet, documentation management system etc.) it'd be difficult to find something like a publicly available real-life use case demo of it. Without much effort, you can check out the real-time collaborative editing demos (https://ckeditor.com/collaboration/real-time-collaborative-e...) that we have on our website.

A while ago we started building our own internal implementation of a collaborative document management system using CKEditor 5 and features such as real-time collaboration with track changes (something like Google Docs) for our own needs - hopefully, once we polish it a bit, we will be able to release it. We are working on publishing a few case studies with existing customers, too.

As for offline collaboration, our current solution switches the editor to read-only when you e.g. lose connectivity, and then the editing mode is back on when you reconnect, along with the changes that were done in the meantime by other users when you were offline. The platform is ready to fully support "offline" writing. We tested some more complex scenarios with one of the users being offline - and it works (however, no periods as long as days of being offline). We focused on delivering other collaborative editing features such as track changes or comments that were more required by our customers. Full support for writing while being offline is still on our roadmap, though.

As for the answer to why the collaboration component is not Open Source: we have currently 40 people in total working on CKEditor (CKEditor 4 & CKEditor 5). Developing such a complex application takes a lot of time and resources and we simply need money to cover the expenses. Without that, we’d not be able to spend so much time on fixing bugs or bringing new features. Also, unfortunately, we learned the hard way that some of the biggest IT companies don’t want to help Open Source projects by spending even a single dollar on them, even if they use it in an application that brings them millions of dollars.

Regarding mobile support: CKEditor 5 works well on mobiles (with and without real-time collaboration). The comment you referred to was about the lack of an online demo of real-time collaboration on ckeditor.com for mobile devices. The reason behind this decision was that we are using the sidebar for displaying comments, which results in rather poor UX on mobiles. Fortunately, we are almost finishing the inline annotations plugin which will display comments inline, without using the sidebar. Feel free to assign a full Kiwi for mobile support :)

Thanks again for the article!

Re: Open source collaborative text editors

#82
post #78
post #77

Earlier quoted context omitted.

Do you have any idea which would be better for a vector based drawing app? The data is mostly strokes (lists of points), and individual strokes generally don't change.

From the introduction: "After over a decade, however, CRDT solutions are rarely found in working co- editors or industry co-editing products, but OT solutions remain the choice for building the vast majority of co-editors. In addition, the scope of nearly all CRDT solutions for co-editing are confined to resolving issues in plain-text editing, while the scope of OT has been extended from plain-text editing to rich te…

I'm not sure what to make of that, though, as there seem to be quite a few different JSON CRDT libraries, for example.

Just after that it says "The contradictions between these realities and CRDT’s purported advantages have been the source of much debate and confusion in co-editing research and developer communities." That's kind of my question/confusion: people writing CRDTs really talk them up, and I can't tell what's true in practice. I have no way to judge the accuracy of this paper myself (I don't know enough to really understand it), so I'm hoping someone who knows this stuff in a practical way can shed some light on it.

Re: Open source collaborative text editors

#83

What many people not fully grasp, at first sight, is that offline support for a collaborative editor is at least an order of magnitude more complex than just building a collaborative editor. In online collaborative environments, solving conflicts is relatively simple, as the changes are supposed to be small. But when two (or more) people are working on the same document without synching it for hours or days, the merg…

This is where differential synchronization shines (basically git). While OT/CRDT are really good for syncing small edits, they suck at being eventually consistent (with intentions preserved) on very large edits.

We make a powerful collaborative word processor for the browser (Zoho Writer https://writer.zoho.com) with complete offline support. This is one problem we'd like to solve in the long term. One way to solve this is to fallback to differential sync when syncing huge offline edits - and present the changes as tracked-changes (underlined and striked-out) to the user. This way the user has the power to resolve the conflicts, instead of the app messing it up by itself.

I'd like to hear if there are better ways to sync large offline edits, with the intentions preserved.

Re: Open source collaborative text editors

#84

What many people not fully grasp, at first sight, is that offline support for a collaborative editor is at least an order of magnitude more complex than just building a collaborative editor. In online collaborative environments, solving conflicts is relatively simple, as the changes are supposed to be small. But when two (or more) people are working on the same document without synching it for hours or days, the merg…

This is an interesting subject, to be honest.

Of course, it depends on the collaborative editing solution. When it comes to OT -- if the implementation is correct, it doesn't really matter how many operations are queued for synchronising. So, it doesn't really matter how long users were de-synced when creating their content. But this is only theory and it applies more to technical side as there might be some semantical problems (intention preservation).

I believe the same is true for CRDT but I am not sure.

So, on one hand - if the editor is working fine for small batch of changes, it should also work fine for big batch of changes. The reality is often more harsh, though, and full of edge case scenarios.

Re: Open source collaborative text editors

#85

Surprised the author didn't mention Quill.js, which works really well with ShareDB, and is fully open source. We've been doing a lot of fun stuff with it - here's a talk I gave recently as a job talk: https://www.youtube.com/watch?v=gN37rJRmISQ . (It worked, I got hired :)). As a side project, I'm working on a ShareDB backed wiki, where we can use rich text for editing pages, but also other components, like spreadshe…

I like what you've done.

Is the FROG repo you linked the repo of the wiki?

I'm just curious as it doesn't mention anything about it being a wiki in the readme (it's also a bit unclear how/what to use it for from the description).

Re: Open source collaborative text editors

#86

I found this recent paper highly enlightening: “Real Differences between OT and CRDT for Co-Editors” – Chengzheng Sun, David Sun, Agustina, Weiwei Cai, October 2018. Arxiv meta: https://arxiv.org/abs/1810.02137 PDF: https://arxiv.org/pdf/1810.02137.pdf It’s well written imo. The conclusions chapter is very good. “In this work, we have critically reviewed and evaluated representative OT and CRDT solutions, with respec…

I still need to read that one, though it looks interesting (yes, I only got through the introduction and summary :)). Let's keep in mind that the authors already wrote several papers on OT (also ones that we based CKE5 on) -- so they have vast knowledge in the subject but may also favor one technology over the other. As much as I'd like to read that OT was the good choice I also want to be cautious in this regard :).

Re: Open source collaborative text editors

#87

Earlier quoted context omitted.

I appreciate that you mentioned a competitor without shamelessly plugging your own product, but out of curiosity, and if you don't mind sharing, what editor do you work on?

You can currently already do good-enough-for-most DOM-level synchronization using any editor, of which we have a few examples. A lot of the examples of RTC out there (apps using TogetherJS for instance) are doing this already. For rich text, we'd like to be able to provide 100% support for a particular editor's capabilities, which necessitates a deeper, custom data model. One of our value propositions is a unified ba…

Could you point us to some of those togetherJS apps? I just recently learned about it in the context of collaborative browsing. How is this related to collaborative text stuff?

Re: Open source collaborative text editors

#88

What many people not fully grasp, at first sight, is that offline support for a collaborative editor is at least an order of magnitude more complex than just building a collaborative editor. In online collaborative environments, solving conflicts is relatively simple, as the changes are supposed to be small. But when two (or more) people are working on the same document without synching it for hours or days, the merg…

This is where differential synchronization shines (basically git). While OT/CRDT are really good for syncing small edits, they suck at being eventually consistent (with intentions preserved) on very large edits. We make a powerful collaborative word processor for the browser (Zoho Writer https://writer.zoho.com ) with complete offline support. This is one problem we'd like to solve in the long term. One way to solve…

> One way to solve this is to fallback to differential sync when syncing huge offline edits

This is another question -- does automatic syncing make sense for huge differences in users' contents? The answer might be no.

OTOH, isn't this a rare scenario? How perfect it has to be?How much of a compromise can the users accept? These are interesting questions which shows that creating this kind of software isn't easy -- both from technical and UX point of view.

Re: Open source collaborative text editors

#89
post #82
post #78

Earlier quoted context omitted.

From the introduction: "After over a decade, however, CRDT solutions are rarely found in working co- editors or industry co-editing products, but OT solutions remain the choice for building the vast majority of co-editors. In addition, the scope of nearly all CRDT solutions for co-editing are confined to resolving issues in plain-text editing, while the scope of OT has been extended from plain-text editing to rich te…

I'm not sure what to make of that, though, as there seem to be quite a few different JSON CRDT libraries, for example. Just after that it says "The contradictions between these realities and CRDT’s purported advantages have been the source of much debate and confusion in co-editing research and developer communities." That's kind of my question/confusion: people writing CRDTs really talk them up, and I can't tell wha…

I found that I could eventually power through the paper. I thought it was beyond me at first. Then I got angry and just shoved piece by piece into my head :) Not in linear fashion, and it didn’t happen quickly. Actully not that slow either once I got going. I found I was maybe rather more of a paper-reader than I assumed I was. Probably you too!!

Re: Open source collaborative text editors

#90

I would be very appreciative if Google made a stripped down version of Google Docs for plaintext editing. There are a bunch of basic integration features that would also be fantastic, but if the product was literally just Google Docs, minus the WYSIWYG bits, and all plaintext w/ maybe some syntax highlighting thrown in, I'd be super happy.

If you're looking for a plaintext collaborative editor, then Quill and a bit of glue-code is all you need. I believe there's even example code that shows how to maintain the document on a server.
Post reply on HN