> Yeah. Text based OT is pretty simple to implement, too. It’s about 200 lines of code, plus a simple network protocol.
Just for clarification, while OT for plain-text (linear model) might be simple to implement, OT for typical rich-text editors (like Google Docs) that need to rely on a tree-structured data model is a whole different story: https://ckeditor.com/blog/lessons-learned-from-creating-a-ri....
Well, interestingly josephg (parent commentor) was part of the team that made the original gdocs editor. And I guess he worked on the Google Wave OT implementation.
Thank god I didn't question what josephg wrote regarding the text-based OT :D
I'm actually part of the team that built real-time collaboration for CKEditor 5. As the article says, we use a tree-structured representation for rich-text data and decided (many years ago) to go with OT. My guess always was that GDocs also uses a tree structure as the internal data model or that at least Google Wave did. I think I based this on a comment from a Google employee who summed up their OT implementation as hard to stabilize, even over many years.
I know it's possible to kind of represent rich-text data in form of a linear structure. This makes the implementation of the OT much much simpler. But then the editor itself becomes much more limited or you need to combine multiple instances of its model to represent more complex data. E.g., AFAIK Quill (mentioned in the other comment) does not offer stable tables implementation. Something that wasn't that big of a deal for us.
Google Docs actually uses a flat array representation of the whole document. Tables/lists and other structures are encoded using control-characters in the plain string. This makes index calculations for OT a bit easier.
How do I know? I work on Zoho Writer - a google docs alternative and we use the same technique :)
Glad to meet you. Huge fan of CKeditor's modular architecture of the editor. Making something with that level of customization and supporting realtime collaboration is not an easy feat at all!
What are your thoughts on CRDT generally? Will CKeditor ever look into adopting CRDTs in the future?
nah, that’s not true at all. have a look at ‘rich-text’[1] which allows for transforms on metadata in a separate stream from the main content. it’s the same basic algo used for OT on plain text.
(i was the cto at a startup which used this to create a multi-user text editor with rich text support in 2015ish)
Actually, back in 2015 when we started prototyping CKEditor 5, we started with this approach as well. Our goal from the beginning was to combine real-time editing capabilities with an engine capable of storing and rendering complex rich-text structures (nested tables, complex nested lists, other rich widgets, etc.). We quickly realized that a linear structure is going to be a huge bottleneck. In the end, if you want to represent trees, storing them as a linear structure is counterproductive.
So, we went for a tree model. That got many things in the engine an order of magnitude harder (OT being one). But I choose to encapsulate this complexity in the model rather than make it leak to particular plugins.
I also talked to companies that built their platforms on top of Quill. One of them ended up gluing together countless Quill instances to power their editor and overcome the limitations of the linear data model but is now looking for a way to rebuild their editor from scratch due to the issues (performance, complexity, stability).
So, yes. You can implement a rich-text editor based on a linear model. But it has its immediate limitations that you need to take into consideration.
> A real world implication is that if you want to add a new operation to a system (...) with OT, you can probably find a way to extend what you have to get it in there, with a painfully non-linear cost as you add more new operations
Exactly the experience that we have in CKEditor 5. OT is awfully complex. However, we can fine tune it for new operations and different scenarios of usage (e.g. undoing changes is one of them). With CRDT, at least to my understanding, we might've been limited to what we'd took into consideration on day one. Seeing how many things we learnt very late in the process (5 years so far, some documented in https://ckeditor.com/blog/Lessons-learned-from-creating-a-ri...) makes me thing that we'd sink the company twice already.
I worked on a prototype for a couple of months which would have been a partial competitor to CK. We went with CRDTs because it was quicker to get something simple and reliable off the ground to demonstrate, but we were pretty sure we'd have to switch to support something for the longer term.
It wasn't chosen to go forward as a focus of the business, but it was one of the most fun periods of commercial programming I've done :)
We went with OT five years ago in CKEditor 5 and we have the same experience. While it would be tempting to try CRDT, it seems to come with too significant tradeoffs in our scenario.
The other aspect of CRDT that's in some scary is what @mdpye explains in https://news.ycombinator.com/item?id=24621113. With OT, if we get the corner cases right, we can tune and extend the implementation. With CRDT that might be game over.
We've been doing quite a lot of research around mobile support in the early phase of working on CKEditor 5. We knew from our past experience that on mobile devices (especially smaller ones) you need a dedicated UI, rather than a responsive version of the same UI that you use on the desktop. When the software keyboard is visible (+ when you have autocompletion bar above the keyboard) there's really not much space for your UI and the text that you want to edit. It means that you need really good control over what's happening on the screen in order to be able to implement a reliable UI.
Anyway, we had big plans for mobile support in CKEditor 5. Then we started doing more research [1] and it turned out there are critical issues with how WebKit works. You can guess, you can try, but with a tone of hacks you still won't be able to guarantee a smooth UI and great UX.
Right now, we're in a state where:
* after spending several months on it, text editing is well supported on iOS and Android (including spellcheck and stuff) – we don't get any bug reports recently about that part,
* the default UI is not working great on smaller devices.
The sad part is – we don't have any bigger plans to address the latter. We have some smaller ideas for making the current UI more responsive, but there will still be fundamental issues that you will face when using it:
* The conflict between the native UI (the balloons/panels with paste/copy/cut/bold/italic) and the custom editor UI. I've been bringing that to the W3C's attention since 2015 and nothing happened since then (most recent topics: [2], [3]). Right now, I don't have the funds anymore to lobby for this (neither have anyone else, apparently), so those topics seem to be completely stale.
* Inability to display your UI and implement functions like scrolling to the caret in a reliable way on WebKit due to its broken viewport mechanics [4]. I even talked about this with one of the Apple devs responsible for the current behavior and he agreed that there may be a problem (a good first step :D), but I got literally zero feedback after the last year's TPAC in Lyon when I presented this issue.
* And more...
IMO, it's due to those issues that we haven't seen a single editor (implementing more than some really basic functions) with a good and stable UX on both iOS and Android. Every solution I saw was flawed in one way or another. I'm not saying that it's completely impossible to build such a solution, but rather that, taken all the obstacles and moderate demand (desktop is still the main platform for rich-text editing), the ROI seems too low for anyone to invest enough in it.
This is really nice context to have. I would generally agree with you that, in the current mobile IME landscape, it's hard-to-maybe-impossible to get close to the text editing UX of a native app with the web platform.
I guess my point of frustration is to watch project after project toss itself at the task of implementing a nice Medium-ish desktop UI, announce a new "standard" for JSON-based rich document serialization, get mobile support about 80% of the way there, and then just... leave it like that.
I don't have enough data to make a firm statement, but I would bet with confidence that that if you include native mobile apps in the calculation (iOS Notes app, Google Keep, Wordpress Mobile), mobile rich text editing is either more prevalent than desktop, or on a strong upward trend that will overtake desktop text editing in the next two years. The popularity of hybrid devices like the iPad pro, where you have a desktop-class processor and screen size but an iOS IME is only going to boost those numbers.
Still, that does not mean it cannot output HTML. CKEditor 5 implements a custom data model, works in the way you described (cancel native actions or extracts stuff from it, apply those changes to its data model and re-renders the DOM if needed), but it still outputs HTML. Thanks to that you don't need a processor to use that content on your page. Plus, there are cases where converting a custom data model to HTML is actually a tricky job (e.g. inline formatting) and even Editor.js chose HTML for those.
Hi! The author of this article here :) I hoped you liked it (cause your message can read both ways :D)
You reminded me that I was planning to refresh it a bit since it's over 3 years old now. I'd like to cover the rise of modern rich-text editors like CKEditor 5, ProseMirror, Draft.js and perhaps dive a bit into what we've learned when developing CKEditor 5 (because after 4 years of work it's actually out by now [1]). If you have any questions or you're curious about some particular aspects, please let me know :)
I loved the article! I used to have to maintain some custom ckeditor plugins related to custom elements, spell checking and autocompletion at a job and that article resonated deeply with me on a personal level. I would love to read another article about the new editors :)
I would love to read an article like that! I'm very curious how the architecture of the new CKEditor 5 compares to younger alternatives like ProseMirror and Draft.js.
Did you try CKEditor 5? It's a modern rich-text editing framework with a rich API. However, it also comes with a lot of polished and ready-to-use features. You can read more on: https://ckeditor.com/ckeditor-5/.
Since you mentioned CKEditor 5, I'll be bold enough to go a bit into off-topic.
CKEditor 5 is an incredibly impressive endeavour, and I've been following it with great interest. However, one of the things that separates it from the competition is the GPL license, which makes it impossible to use the editor in a permissively-licensed (Apache2/MIT) open source project. Your founder has indicated a readiness[1] to grant a custom license to such projects.
So, I'm wondering whether that is still the policy, and how that's been working out in practice. Have any projects taken you up on the offer? Have there been any unforeseen problems? What are the legal limitations imposed (on distributors/forks of the project, for example)?
Yes, the "Free for Open Source" initiative is up and running. For now, we didn't promote it a lot because we wanted to learn how it works, but from what I know, the custom license that we proposed is already used by a couple of projects.
Based on the feedback that we got so far, we're right now working on a simplified version of this license. Its initial version still had some restrictions which didn't work for Apache2/MIT projects with a commercial branch. Plus, it was simply too long for normal people :). We're removing these limitations. Once it will be polished, we will talk about it more officially on ckeditor.com.
Which FOSS license? Because if it's a permissive one, like MIT, BSD or MPL, then you get results like we did with CKEditor 4:
> From these thousands of businesses and millions of downloads, a very small group (less than 0,5%) decides to enter into business relations with CKSource.
CKEditor (a rich-text editor) is this kind of really complex piece of software which requires years of experience and years of development. It's also a piece of software which is complex enough to scare people from contributing to it. So people use it for free and report bugs to you. That's all. With that conversion rate about 0.5% and a rather niche market, it's possible to slowly grow your business (as we did – CKSource is 40+ people today), but hard to keep up with the world.
Just to give a context – CKEditor 5 (which was written completely from scratch) required 5+ experienced developers working for more than 4 years right now. Therefore, for CKEditor 5 we chose GPL2+. We hope to have a more healthy paying/free users ratio. The future will show us if that's a good direction
BTW, you say that:
> commercial licenses can be a serious pain to navigate in many companies
From my experience, it's actually the opposite. Companies like our commercial license because it's easier for them than going with e.g. LGPL or MPL and hoping they won't violate it.
I agree completely - there are FOSS licenses that are easier to make money with than others. One of the most frustrating things I regularly encounter on HN is the “MIT/BSD is best, don’t use anything else” mentality. I think some of that is likely coming from the ease of use commercially (I worked for organisation who’s legal department literally said MIT/BSD = green, GPL2 = yellow, others = red).
But as you have yourself pointed out, it is (or at least may be) possible to make money as a commercial entity whilst still using a FOSS license, without entering the netherworld of “what is commercial use” arguments that these bespoke licenses create.
P.S. I know CKEditor very well, having used its predecessor FCKEditor on a small website for a local charity over 15 years ago! So thank you for continuing to support FOSS :)
