Hacker News new | past | comments | ask | show | jobs | submit login

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!




> The platform is ready to fully support "offline" writing

how did you solve the merge when somebody comes online again but creates a conflict with his changes?


I don't like "merge" word because it implies how the problem is solved. "Synchronise" would be better, as there is no merging, actually.

We use Operational Transformation, so all the changes are stored as operations (with their most important property being path - the position where the operation happened).

When a user comes online, they try to re-send all the operations that are buffered and not yet sent to the server. Then it is a matter of transforming these operations by the new operations that happened in the meantime (when the user was offline). Of course, the user also has to accept the new operations.

This is a bigger / more complex version of the basic problem of the real-time collaboration. During real-time collaboration with all users online you might need to transform your operation by maybe several other operations at most. When you go offline, it might be tens or hundreds of operations but the problem is basically the same, just bigger.

The quality of the transformation algorithms will make a huge role in how well the user intentions will be preserved.

"Platform is ready" means that the theory behind our solution is correct and that we checked some moderately complex scenarios.

Edit: still, the base scenario is that the users write "online" and "offline" kicks in when you lose a connection (for hours, even). If we are talking about "everyone writes offline and then they magically merge" then I think this might be a totally different feature (and maybe even outside of the editor and inside the CMS).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: