Rich text editors are an integral part of content creation and content management workflows, but they can often present challenges for developers when it comes to robustness, extensibility, flexibility, and accessibility. What are some of the considerations you should keep in mind when evaluating rich text editors, especially for mission-critical systems like the application Tag1 is building for a top Fortune 50 company?
In this Tag1 Team Talk, we explore the new generation of rich text editors, which are based on a well defined data-structure rather than HTML, but still can export to Markdown or HTML. This allows us to tackle new requirements organizations have, including video embedding, cross-device support, and keyboard-navigable editors. After diving into some of the open-source solutions available in the market, such as Draft.js, CKEditor 5, Quill, Slate, and TapTap, join moderator Preston So (Contributing Editor) and guests Nik Graf (Senior Software Engineer), Kevin Jahns (Real-time Collaboration Systems Lead, Yjs creator), Fabian Franz (Senior Technical Architect and Performance Lead), and Michael Meyers (Managing Director) for an in-depth conversation about why ProseMirror is the best tool for our client’s project requirements.
Be sure to check out our related #TagTeamTalk, A Deep Dive Into Real Time Collaborative Editing solutions (e.g., Yjs, Collab, CKSource, etc.)
------------------------------------
Further reading
------------------------------------
ProseMirror Editor
------------------
https://prosemirror.net/
CZI ProseMirror: https://github.com/chanzuckerberg/czi-prosemirror/
Prosemirror Tables Demo: http://cdn.summitlearning.org/assets/czi_prosemirror_0_0_1_b_index.html
ProseMirror Atlaskit Yjs Demo: https://yjs-demos.now.sh/prosemirror-atlaskit/
Draft.js
------------------
https://draftjs.org/
https://github.com/nikgraf/awesome-draft-js#live-demos
https://quilljs.com/guides/designing-the-delta-format/
CKEditor 5
------------------
https://ckeditor.com/ckeditor-5/
CK5 Demo: https://ckeditor.com/ckeditor-5/demo/
Quill.js
------------------
https://quilljs.com/
Quill.js demo: https://quilljs.com/standalone/full/
Slate.js
------------------
https://github.com/ianstormtaylor/slate/blob/master/Readme.md
Slate Demo: https://www.slatejs.org/#/rich-text
TipTap
------------------
https://tiptap.scrumpy.io/
Fidus Writer
------------------
https://github.com/fiduswriter/fiduswriter
CodeMirror
------------------
one of the most popular code editors for the web
https://codemirror.net/
For more on Web Components and how they're being used, see Web Components.
---Text Transcript
Preston So: - Hello, and welcome to the second ever episode of the Tag Team Talks. Today we're gonna be talking about rich text editors and some of the solutions that are out there in this very exciting and growing space. First thing I want to do, though, is get a little bit of a look at our guests today. My name is Preston So. I am the moderator and contributing editor to Tag1 Consulting. And I'm joined today by several amazing folks from all around the world here to talk about rich text editing.
Michael Meyers: - Awesome. My name is Michael Meyers. I'm the managing director at Tag1. I handle business development, sales, partnerships, marketing, strategy, client relations, things of that nature.
Kevin Jahns: - Hi, I'm Kevin Jahns. I'm located in Berlin. And I'm an expert for shared editing and CRDTs. I currently work for Tag1 consulting on a realtime system.
Nik Graf: - Hey, I'm Nick. I've done a lot of frontend development over the last couple years, and also was digging into Draft.js, actually built a plugin system on top of Draft.js. And now doing a lot of work on the same project as Kevin, the realtime collaboration stuff with ProseMirror.
Fabian Franz: - Hi, my name is Fabian. At Tag1 I'm currently a senior technical architect and performance lead. But on this project I'm especially excited about bridging the gap for the editors. And I'm a Drupal enthusiastic, Drupal 7 core maintainer, but also a longtime Drupal Aid contributor where we're also kind of having this switch over from CKEditor 4 to maybe CKEditor 5, so going to the next generation. So this is really exciting to be working a project where we're exploring all of that.
Preston: - Thanks very much to all of our guests. It's a real pleasure to be here with all of you today. This is a very meaty topic. We're gonna be talking for quite some time about this, I'm sure. But first, I just want to say good morning, good afternoon, good evening, to wherever you are in the world. And if you haven't already checked it out there's actually a previous webinar that we've done related to this topic on collaborative editing. It's about how it relates to the ways in which people work today. And I want to make sure that we refer back to that webinar so please take a look at the link also available on this page. Alrighty, so let's go ahead and get a quick background on Tag1. Why are we interested in rich text editing, Mike?
Michael: - So, Tag1, we handle mission critical systems, emergency management. We've helped organizations like the American Civil Liberties Union go from raising $4 million a year in donations to over $120 million a year after President Trump in the U.S. came into power. So we do a lot of performance and scalability. We do high availability. We work with a lot of Fortune 500 companies like Symantec doing cybersecurity, infrastructure management. For this particular project that we're gonna be talking about today we're working with one of the top 10 Fortune 50 companies. They are rebuilding their intranet. It's a highly available, highly scalable, mission critical system used across 200 countries with over 20,000 active users in well over a dozen languages. Realtime collaboration is key to how the modern workforce operates. I spend a lot of my time in things like Google Docs collaborating with the team on all sorts of things. And while our goal with this intranet is to integrate a lot of different systems and not reinvent the wheel, so for example, you'll get a summary of what's going on in Slack on the intranet but all that information comes from Slack and the idea is just to link you off to Slack. These days, people use a lot of third-party tools for what they do best. The challenge with that is that they are disparate systems. And so if you have Box, and Slack, and Quip, and all these other things, it's hard to know what's where. So this system really organizes all of that with centralized authentication and user management so you can, say, create a space for a particular group and it will spin up all of the necessary artifacts we need, from say Slack to Quip, manage permissions. You can use any of these systems independently but everything is sort of synced, meta searched, and managed across this centralized system. And then a key component of this system itself is collaborative editing. And they have, as you can imagine with a global workforce of 150,000+ employees, they have a lot of people with different uses cases and needs. And so, some people, let's say technical people, love Markdown and want to work in one type of editor. People in other groups and departments might prefer WYSIWYG. Some people want to be able to edit HTML directly. And so, the reason that we're looking at editors on top of the ability to do realtime collaboration and work together on information in realtime is that we need to accommodate a lot of features, plugins, enhancements, and different users in different spaces. And so we took a wide range, an assessment of a wide range of editors in the marketplace, did an analysis based on our feature requirements, narrowed it down to a field that we're gonna talk about today, and ultimately selected an editor.
Preston: - I think this landscape is quite broad. There are so many options out there, and it's very difficult to choose which ones are appropriate, especially given that there are so many requirements that people have today. And being able to actually choose based on a variety of different features, which we'll talk about in just a little bit, is a huge prerogative. I mean, there's two areas that you just mentioned, Mike, that are very interesting. And the first is the realtime collaboration which has its own challenges and its own difficulties. Which was the subject, by the way, of our inaugural Tag Team Talk. And of course our second topic today, which is really what a rich text editor is. And combining those two really unleashes a lot of power for these content editors, but it is also very challenging from a technical standpoint. But let's go down to the very, very basics here, and the fundamentals. Sort of in its most basic sense, how would we, as a group, define a rich text editor?
Kevin: - I think that's really, really hard to make a general description of a rich text editor. I think most people think about Google Docs when they hear that. But I would say that a really basic rich text editor is something that supports boldness, italic, and headlines. That's it for me. Because often you really need that feature set. That's basically what you have in Markdown and that you want to have in all the other editors. Sometimes you write a blog post. You basically only need these features. For us developers it's really important to have code blocks too. I think that's a really important feature. But I don't think everyone agrees here. There's links and tables. Actually, a lot of people expect tables but not all editors support tables. So for me, a rich text editor is, yeah, something that supports this, contrary to pure text editors that only support working on text, maybe only paragraphs, and no rich text formatting.
Preston: - Was there a certain minimum, like a threshold that you wanted to reach in terms of the number of features? I know that you all have done a really strong comparison of all of the features available. Was there a certain point where you said, okay, well, we can put a dividing line here where we can say, all right, everything above here we can definitely look for, but everything below this line perhaps maybe we should strike out of our requirements?
Kevin: - I think a baseline for this project, yeah, we had a baseline, a feature set that we want to implement. And for our use case it was really important that our editor is adaptable. And this is not a requirement for all the projects that are out there. Sometimes you really just want to have a plug-in editor that just works and does the basic stuff right. But for us, we wanted to do some custom stuff, and some editors support that, and some not as well.
Nik:
- I could dive in here and give one example that Kevin mentioned. This is for example the tables. I worked a lot with Draft.js in the past, and I know you can do tables, and it's possible. But if you want to do more than just a simple text field and then have, rich content, again, in the table field, this is really, really hard to do with Draft.js. So what people came up with ideas like Draft.js per fields, like editors per field in the table. And then this gets really, really heavy because this has to run on the web browser. While others support this because the structure internally, how the data is managed is completely different. This is completely different. Basically, depending on what your needs are it completely rules out certain editors right away.
Fabian: - Yeah, that's also what I've found in my research of editors. Tables are really tricky with an image in a table, where every normal person is like, hey, that's so easy, it should just work in that. I've also seen for two other editors, either Slate or Quill, where the table plugin was basically instantiating another complete editor within that and then doing some magic to hide the one toolbar, show the other toolbar, so that it's still a seamless experience. Once you go away from those basic features like bold, italic, those they all can do, code play, quotation maybe a little bit more complicated. But basically, what's kind of used, what you are used to from all the old editors, most can do, that's not a problem. But once you get into the nitty gritty and really want some features like autocomplete, you type something and you get a table or something like that, we have that not yet, but it's so useful, and so practical, and so nice. But some editors, it's just way more harder to implement than others.
Preston: - I think we can all agree that as it gets more and more complex you kind of question the usefulness of some of these, especially the inline tables or some of those formatting options.
Preston: - Well, I think we've talked a lot about formatting, and clearly, formatting is a very, very strong interest to a lot of the content editors that we work with on a daily basis. But I think we also, Mike mentioned earlier something very interesting which was about document formats and the interchangeability between those. That's also a very important feature of rich text editors. Because you can do whatever editing you want to, but if you can't extract it and move it into a different format, or make it usable for other systems, it doesn't make any sense. And so I'm curious, when we talk about these document formats, do all of these editors support Markdown, HTML? Do they all support rich text? And I guess my even more pertinent question here is how easy is it to switch between them in these editors, or is it possible at all?
Kevin: - I think it's important to distinguish the underlying document model of the editor, that is often JSON-based, especially in rich text editors, and how you interact with the editor. Most editors somehow support some positional parameters. So, insert something at position X, something like that. Because that's how most humans comprehend text editors. So we somehow try to port that to rich text editors. There's some editors like ProseMirror that are more structured so you really need to say, okay, I want to insert something in this paragraph, inside this table, at this position. But this is also translated to index parameters. Because also ProseMirror, which is structured internally, accepts something like index parameters. So, insert something at position one, for example. And I really like that, especially... Like, in comparison, Quill.js has also an internal model that is purely based on position parameters. It accepts changes that are defined as the delta format. And I really love this data format because it's a really easy description how to insert something into the editor. It's index-based. And it is also perfectly suited for collaboration. But something that is really hard when you only work with index parameters is designing tables. So, when you work with tables, I think something like ProseMirror which is more structured, it's something really cool.
Fabian: - What Kevin said is very great and important but might have been a little bit too much already, too deep already into what our audience expect. So I would really like to step back and just show what is this kind of document model. And we are here at a very exciting point for me personally because we are at a transition point. All of the old generation editors, CKEditor 4, and whatever you all have, some nicer, some not so nice, they all have been built on something that's called a contenteditable. This contenteditable was basically supplied by the browser. It allowed basic formatting, and every of the trillion browsers that are out there, even browsers within the same name, implemented it differently. It was a huge headache. So all the editors said, no, no, no more contenteditable. We really don't want that anymore. The huge advantage of this old generation of editors is you threw them some HTML, it was outputted out of Word, and they could take it. It might have not looked nice, but they could take it. They could see it, they could display it. You could even edit it. So you just threw some HTML on them and then you get also HTML out. So for something like Google, that's perfectly suited. You load the HTML from the database. The user edits the HTML, now it's saved again to the database. The new generation of editors, CKEditor 5, ProseMirror, Quill, they are all having some internal document model. And we are seeing that a lot also in other cases of the web and everywhere, that we're kind of using these extra technologies, these languages that allow to express the same what was in the HTML, but differently. And because they are all having these internal document models what you can do is you can, for example, take... In theory, at least, you can take the same document model and ones display it as What You See Is What You Get, but ones who could also display it as Markdown, as long as you don't have something that Markdown doesn't support within it, and you can basically transfer it back and forth. Because the only thing that changes is the transformation from document model to what the user is editing, and how you are working on the document model. This was the other thing. And that makes for really cool demos. We'll put in a link to a ProseMirror demo where you can really, you have the technical person there, no Markdown, all comments out of the hat, they're just putting in Markdown. You have a non-technical person, they can collaborate on it in the same document because the other person can just click on bold and it's bold, and they see it as What You See Is What You Get. And that's so cool in the new generation of editors. And later we'll talk a little bit about the challenges, but I think that was a good introduction.
Preston: - And just to add a little bit even more context here, I think when you talk about, Fabian, the ways in which we've evolved over time, I mean, long gone are the days when we had those phpBB formatting toolbars which were limited to let's say three or four different buttons, and they never worked half the time. To nowadays, this very advanced and almost abstract way of working that is really kind of a layer above, where you're talking about working with JSON as opposed to working with direct HTML or direct text. We're actually talking about an object tree, which is really amazing, and I think is very compelling. So let's go ahead and move a little bit towards some of the more business requirements here. I do want to talk a little bit about this Fortune 50 client that you mentioned. We know that all of these editors and all of these powerful tools do have the functionality to do these formatting changes, have the abstraction layer as part of this new, this kind of new document model that we talked about. But I wanted to ask, there's kind of differences in how each of these editors like ProseMirror, like Draft.js, like Quill, how they manage all of the underlying data, and also how customizable they are. Can we talk about some of the key requirements here? What's maybe some of the major characteristics that you all wanted to see come out of this project?
Michael: - Before we jump into the technical stuff, I think one of the key things, well, first of all, it had to be collaboration ready because we're integrating this with a realtime collaboration system. But beyond the extensibility that Kevin talked about, which is critical because their needs are constantly changing, we need to integrate it with a lot of different third-party tools and systems. We want to add things like @mentions that tie into central authentication. I'll let these guys dig into that. There were a couple of business requirements. One of them was, you know, prove it. We looked at some really interesting editors that are still in the earlier stages of development, and we could swap them in in the future. That is another aspect of extensibility. We may choose to change editors in the future, or give different users different editors. But for launch we need something that's proven. Something that is really stable, that has a robust open source community behind it that is continuing to develop it with maintainers that are really responsive. We wanted to make sure that it was being used in enterprise production by large organizations. So, ProseMirror, for example, is used by The New York Times. And they've written some great posts about it. They were generous enough to get on the phone and talk to us a lot about their experience to sort of confirm some of our research and thinking in real world scenarios. That was really critical just from a, before we could even evaluate these editors and dig into the features, there was sort of a minimum bar.
Fabian:
- Yeah, and also what was important from the proving standpoint, ProseMirror for example, and we will come later to that, Confluence almost everyone knows, many work with it. It's built up on Atlaskit, and Atlaskit itself is built upon ProseMirror so that was another plus point. The CZI, Zuckerberg Initiative nonprofit, they are building some Google Docs-like clone based on ProseMirror. Also very interesting. So we had several things to just work with, and to see, and use in that. You use those demos, and they just work. Tables look great, things work in that, so that was a huge plus point here for ProseMirror in just being proven by being used by other larger organizations.
Nik: - Maybe I can add a word to Atlaskit. I mean, we'll kind of dig in later. But Atlaskit, as Fabian already mentioned, Confluence is built on Atlaskit, but not only Confluence. Basically every Atlaskit is this designed system from Atlassian, and everything we're building at the moment, everything we're rebuilding, redesigning, is built on top of Atlaskit. So the Atlas editor, core editor, built on top of ProseMirror in their design system. And this also gave us in terms of like, I don't know, kind of showing off at the client a good headstart in the beginning. I mean, they had a different design and they had different widgets, but you could take a lot of that stuff, put a different design on top of it, and get a lot these tools out there. So, while it was not really a requirement, it was a really, really good way to impress early on. And yeah, because Atlas, Atlassian has done a great job with Atlaskit it could give us a good headstart. And yeah, accessibility, multiplatform, all of that, is built in.
Preston: - Let's dig into some of these. I think, Nick, you just mentioned multiplatform. I mean, this is a really interesting kind of idea where you should be able to use a rich text editor on whatever device. On a phone, on a tablet, on an Electron app. Can you talk a little bit about how you thought about multiplatform and why was it so important to these folks?
Nik: - I think in general, the world is becoming way more mobile. And while desktop is still in the use case, probably, for this intranet, but people more often check... They want to edit something on mobile. And while we currently don't talk of it, we wanted to pick a platform that we later on can expand to it. I can tell from, like, some editors, they have their fair share of troubles with mobile because simply the environment, it is different browsers behaving differently, so the underlying document model sometimes already struggles. Mostly they're working fine and it's a matter of your IUX. But yeah, you basically want to pick something that definitely works on all platforms so you can expand in all directions.
Preston: - And one thing you just mentioned also as well, Nick, that I wanted to call out is the notion is extensibility. You know, third-party integrations, being able to work with other tools. One thing Mike had just mentioned was the notion of being able to tie in @mentions and integrate that with the central authentication system. I also know that there are other third-party tools you want to integrate with, and that you see as being important for these rich text editors. Can you give some examples of those? All the group feel free to jump in as well.
Nik: - Yeah, absolutely. Let's say you want to reference a Dropbox file, or a Box file, or you want to mention another user. These are then custom nodes. So you have an editor that only supports the standard HTML text and doesn't allow you to make your own nodes, then you can't do this. That's why this goes back to this document model. Basically, the document model of the editor has to be extensible so you can actually add your own, extend it, and then allow to build a user interface to add these custom nodes in there. And then however you want to implement them, you can just reference an ID to a GitHub issue, for example, and then you could load the data on demand or you could actually put the data in the document. This then, it ties together into, like, into this authentication system, and how you load the data, and so on. This is very dependent on the needs of security and customer requirements. But in the end, the gist of it, you want to be able to create something where you can add a toolbar item to add GitHub issues and connect them, and have them in the rich text document. This is something where you... I mean, you could have for example even still custom markdown syntax. This is where WYSIWYG usually outperforms Markdown or other systems, by far, because the experience is so much better.
Fabian: - For example, hover over them and then it would show you all the details of that GitHub issue, if there's a pull request or not, et cetera. Possibilities are endless, obviously. And I think that's so very cool about that. What's also really great about this kind of editor integration is that there's so many possibilities in extending that. For example, one thing we didn't talk yet about much, correct me if I'm wrong there, but we're building everything on React components. React, you just have your standard React component for like an autocomplete and then you can put it in the editor. And also another nice thing here about ProseMirror where you have the display in the document and how it's displayed in your document what's outside your document different, and that's also another important part for accessibility, which we probably also wanted to talk about.
Preston: - Absolutely, yeah. Accessibility is a topic that's very near and dear to my heart personally. I know that, Mike, you just mentioned earlier as well that when it comes to a large Fortune 50 company like this one, being able to work with this very large workforce that has a variety of different abilities and a variety of different needs is important. We alluded earlier to some of the challenges around accessibility with rich text editors. We talked about things like contenteditable, the contenteditable attribute on DOM elements, ARIA labels. I know that we've looked at some of the capabilities and we've talked about some of the nice things that these editors have. Are there any that I've missed besides the contenteditable and some of the ARIA features?
Nik: - [Nick] Kevin, you want to take this, or should I?
Kevin: - You do, please.
Nik: - In general, I mean, a lot of accessibility you get out of the box if you have the same content... Or, a document structure in HTML. So if you have like headlines well structured and so on, it makes it easier for people, for the screen readers and so on to parse the content and for people to jump around just by their voice input. But then if you... If you actually make popups, dialogs, if you have toggle buttons, that you get into the nitty gritty details, if you make your custom ones you really have to take care of accessibility by your own. If you look at all the standard toolbars and buttons that a lot of these editors provide, or come with, they have accessibility built in. And that's really good because that shows that this is already, like, a standard, that it's kind of expected. But as soon as you start to build your own, like, @mentions, or a GitHub plugin to reference pull requests, and you're doing your own popup and dialog, you really have to take care of yourself, take care of it by yourself. This is still a lot of work. We were fortunate that Atlaskit did a lot of good stuff out of the box. We already got the feedback. There are a couple of improvements we can do. But that's okay. The initial response was quite impressive. Maybe the gist of it is like, even with these new editors, although they're using contenteditable, you can make them very accessible but you have to, as soon as you do custom stuff you have to do it by yourself and you have to take care of it.
Preston: - Yeah, and I think that, you know, you just mentioned this notion of all of the custom work you have might potentially challenge some of the accessibility and be a problem. This is where having that notion of great flexibility, and extensibility, and customizability, comes with great responsibility as well. I know that one of these you mentioned was the popups. For example, having that autocomplete widget show up with the @mention, that's very challenging. As somebody who likes to think through how would I build that accessibly, I actually don't know where I would start. That's a very challenging one.
Nik: - We very recently had a call with an accessibility expert to talk through that one. And yeah, it's... There are things like... I've built a lot of React components in the past that were focusing on accessibility, but even I learned in this call a lot about your concepts like live regions. You can have a live region in your document and then you can announce, basically, state changes. So for example, one thing that we learned that we're currently not doing yet, but we definitely want to, is if you toggle, if you have some text and you toggle it to be bold, you should announce that. You should announce the state. Is it now bold, or is it not bold? Because by just hitting the toggle, if you listen to the voice, the screen reader will just tell you, you toggled the bold. You toggled the bold status. Like, uh, okay, but which one is it now? This is very, very interesting. You really... What I learned basically is turn on the screen reader and dim your screen so it's black and just try to... All the actions that you usually do in this text editor, try to do them just by navigating around with your keyboard or with voice. If you can get through it, then you're in a pretty good state already. By doing this test and this call, and learning about all these things, we noticed a bunch of things that we're missing. But we're working on it. It's an interesting journey.
Preston: - Well, I know what I'm gonna be doing this evening after I get off work. It sounds like actually a lot of fun. Like, playing the game Myst or something. I know that there are also some specific requirements that were more interesting. And I think that there are definitely some interesting implications that come about when you mix rich text editing with some of the other ways in which people like to work with components on the page. Like, maybe the most important component or most popular component right now, React components. How exactly have you thought about things like embedding React components or embedding videos? I know that you've thought about actually placing React views straight into these rich text editors. How has that worked out for you all?
Kevin: - I think that's definitely one of the more interesting things about ProseMirror. Because a lot of people seem to do that. They plug in their rendering engine, like there's UJS. I know a project, TipTop uses UJS instead of React. Other projects like Atlaskit just build on React to render custom node views. And you can basically render everything in the editor that you would render on a website. I saw a project where you render a PDF using a React view because there's this great PDF, React-PDF. I think it's called React-PDF. It's a really cool project. And you just plug it in, and you have a PDF inside your editor. That's really cool, right? There's a lot of other stuff that you can do just like that. And because ProseMirror is already built on this concept of mutable state it's a really nice adoption to just use React within ProseMirror. But because you can do everything without React, I would argue that in Quill.js it's really hard to use something like that, React inside the editor. But still you can do everything you want. You can build your custom tables and stuff like that. But React certainly makes a lot of stuff easier because they have a lot of knowledge in React. So, it really makes stuff easier.
Fabian: - Not only that. There's also the possibility to just reuse components and then combine the best out of the React world. That is also important from a perspective of how to get developers for this project, that really we focused on those collaboration developers as well as React developers to get the best of the best.
Kevin:
- I think we can all agree that you shouldn't manipulate the DOM manually anymore. For the editor itself, we have ProseMirror to handle the DOM. And for custom views, like for any kind of custom stuff, for example how a table is built, like there are a lot of divs around there, a lot of CSS, I wouldn't do that directly in the DOM and manipulate that information in the DOM directly. There are a lot of edge cases that you need to handle, and you can do a lot of stuff wrong. So, React really helps, I think.
Nik: - There was one more specific requirement that is probably worth mentioning, is our comments. We have these annotations or comments. And this is a very interesting aspect that we learned over time. There was for ones this requirement that for a different permission level it shouldn't be part of the document model, so we wanted to have that out of the document model. But it's also really interesting that if you start to do an annotation and you share the document model collaboratively on realtime, you don't really want to... If you're making a draft of a comment, you don't want to share that realtime. And this is the same for let's say @mentions. If you start typing, you don't want the other person on the other end see the autocomplete suggestions. This needs a little bit of rethinking because you basically have parts. The document model is really like the content that you want to share realtime. But there's the other parts like user interface elements or annotations that are seen in draft mode that you want to keep out of it. And then that's really, really useful to share the same component library so you can actually stay in the same system and not build the editor with one UI library and then build these other user interface elements with another library. It's really handy to use the same thing. It keeps us sane and easy to move forward.
- [Kevin] Well put.
Preston: - Let's jump into some of the actual tools that are out there. I think that we've heard a lot of names thrown around. There's been a lot of very interesting technologies mentioned, and a few that we haven't mentioned. We've talked about ProseMirror briefly. We talked about Draft.js. Very briefly talked about Quill and CKEditor 5. But there's also some others. There's Slate and TipTap. What are some of the top open source... When we look at these open source editors on the market, which ones were the ones that really were compelling for you all? And what were some of the strengths and weaknesses?
Kevin: - I think, for me, the biggest strength... Like, we can talk about each of the editors separately. Maybe we go from the most popular ones. Maybe Fabian can explain something about CK 5. He has the most experience with that.
Fabian: - Sure. CKEditor 5 is the popular successor of the very, very popular CKEditor 4. It also switched to a JSON-based model. However, they do up and downcast everything so what you basically in the end still get is HTML. So you have HTML, or you have structured HTML. So, for example you cannot have your hello tag. The document would just not know, what the heck is a hello tag, or a blink tag? It would just ignore it and everything that's in it. Because what it does, when it loads the HTML it loads it into its own document model which is also JSON-based, and then it puts it out. Basically, CKEditor 5 is pretty strong. It has good accessibility. And it also has nice collaboration. The collaboration just had one big flaw. It was not open source. This was unfortunately a deal breaker in terms of the extensibility in that, and also putting anything out for everyone. I mean, Drupal is open source. We work a lot with open source at Tag1. We love open source, and it's so cool that Kevin, as the developer of Yjs, is here. That's also kind of how we found Kevin and the other three. We directly talked with the people who are developing these editors and checked them for our project here when we were interested in some part, et cetera. That was kind of the team we then settled on. But CKEditor 5 is still a little bit young in its thing. It has just recently gotten out of beta. ProseMirror has a little bit longer history in being stable and being used for those things. It will not be a concern because some other big players at settling on CKEditor 5. But just saying experience in how you long you work with something is not worth playing around. And then there's a huge compatibility break with CKEditor 4. So what could have been a huge advantage with CKEditor 5, that all of our Drupal backends will directly work with it, et cetera, is no, because there's just a real break between. So, CKEditor 5 is a completely different product than CKEditor 4. Which has its advantages, but as there is no backwards compatibility, and the collaboration module was not open source, we looked more at the other editors. Slate, for example, we've not talked much about it. It's a great editor. It has, from what I've seen, the nicest backend system. It's really cool, very nice in that, but it's beta, and it's beta since a long time. And we want something proven, we want something stable. And something in beta where there could be hard BC breaks was just too much risk for us here in this project. Nick can maybe talk more about Slate because he knows. Draft.js was more like the original Facebook thing, monolith. It's a great editor. It has a nice backend system, it's React-based. It is harder to extend overall in that, and it's also aged a little bit in that. It's one of the more older editors in that. Also, the community is not as active as, for example for ProseMirror, where it's mainly Facebook committing some patches here and there and maintaining it at the stable state. But in the end, it didn't have the features we needed. So yeah, that was kind of the thing. TipTap with roo. If anyone needs an editor for rooJS, use TipTap, it's great. And it's also ProseMirror, basically, so yeah. It's kind of like a product for ProseMirror for roo. That's cool. And then we ended up with ProseMirror and Quill, and that was kind of the huge race between ProseMirror, Quill, going that. Now, Yjs supported both, so it was also no thing here. But in the end, ProseMirror won basically on the experience. Also the tables plugin looked much nicer in its experience, and how it looked and everything. Quill, the database format is great. It's also a collaboration ready editor. It directly works. But you are then... You need to use the data format it provides, and you then need to use ShareDB. And that again was putting our flexibility a little bit to the test. It's also OT-based, which we talk a little bit about in the other talk. If you're interested, check that out. And we want really something that, where in the end, maybe we'll never get there, maybe we will, but in the end we could at least think about a future of offline editing. And that's again something we talk about there. But Quill and ProseMirror was a really nice race in that ProseMirror is more giving you a framework where you have like nothing and you build your own editor, and Quill is like a ready made editor. You plug it into your application, it just works. It's great in that. But as you add Atlaskit, then Quill got out of the race.
Preston: - Yeah, I understand that... Oh, sorry, go ahead.
Kevin: - I think this was one of the bigger selling points. I think we had Quill and ProseMirror in the end listed down, and we compared it. Like, Quill.js has ShareDB. It's a proven concept, operational transformation. It also works with Yjs. There are a lot of companies that already use Yjs with Quill.js. And then there's ProseMirror. ProseMirror has all these teachers, a great community. I think it has a really interesting concept. And most modern editors nowadays, like all the new editors that pop up, for example Atlassian, they are all built on ProseMirror. We also have the Collab module which is kind of similar to OT. It's like a reconciliation approach. It doesn't really handle conflicts as well as operational transformation, but it clearly works. It's And also, Yjs works with ProseMirror, so I got you there because either way, we could choose any of the editors with Yjs. And this is what I really wanted to do. I really explained that and why we did that in the last webinar. But I think the biggest selling point I felt was one, the community behind ProseMirror, and when we saw Atlaskit and that we could just build on top of Atlaskit. Because we had this existing editor, a lot of features, nice tables, nice interactions. This is, I guess, a big selling point of ProseMirror. And a lot of open source components that you can just use, plug into the editor, and it just works. So yeah.
Preston: - Absolutely. One of the things I know, Nick, you mentioned about ProseMirror was the fact that Atlaskit helped so much more. Is there anything more that you wanted to mention about Atlaskit? I think it's a very compelling story.
Nik: - I think not much more to add. I quickly could repeat that because there's so much there that you really, you can simply start using Atlaskit then you have a good headstart. The biggest trouble you might have, and we went through this, is that this is a big mono-repository, so we had to take out the parts, the core editor, that we needed, and then basically continue to use the rest from Atlaskit and take the bits and pieces. Like, slowly replace the bits and pieces that we actually needed to be changed. But this was like, from a demo, or the experience in this project, this was very good because in a very short period of time, I think it was just a matter of like two weeks or so, we had something ready to show that the client could try, use, and actually feel. And then obviously if you then can test with re-users and so on, or potentially your re-users, you're making better decisions than like, just coming up with, like, hey, and we might to do this, and that, and have a button here. But if it takes you quite some time to slowly build it up than rather starting from something that is fully fleshed and then replacing bits and pieces, I think that was for, like, product thinking and product development, a really compelling story. It was possible for Atlaskit.
Fabian: - Definitely Atlaskit very great for us. And that was what Nick was saying was part of our strategy with this client, that we are showing progress every two weeks, and a huge demo. And with not only the client itself but there's a huge stakeholder team that can all watch the progress of that, how it's done. That was really great to make a great impression quick. But not only a great impression quick. What you shouldn't undersell, Nick, is how you definitely improved the build system. Because I think it took like three minutes, at the start, to just build everything, and now you've put it down to 30 seconds and rebuilds are like 10 seconds. No longer like 30 seconds wait time. Like, change some CSS, wait 30 seconds, drink a coffee.
Nik: - We should say there, props to Sebastian, to me. We was digging into the webpack configuration and getting the hot rebuilding working with good compile time. This was really helpful for faster development. One thing I could add there, though, is like about Atlaskit. Atlaskit is not built with realtime collaboration in mind. For example, certain features, they do things like they change the document model for just like showing different user interfaces. So for example, the @mentions that we are building, and the annotation or commenting section, we basically, we cannot use what's there in Atlaskit or we have to adapt it and change it. Otherwise it would be synced across to other users, and we don't want that. So, while Atlaskit was a good start, we now have to really, especially with this realtime collaboration in mind we have to change a lot of things. But that's fine. I think this was the strategy and the approach, and it was a good one. Highly recommended.
Kevin: - I think it was built with realtime but they use a custom version of the Collab module, which is like a different realtime approach. So we just plugged in the Yjs plugin so all the data that you have is shared immediately. And I'm sure that they have some, I don't know, filtering on the backend happening, filter that out, like all the data that you don't want to share. I'm not exactly sure how that works. But also, backend to the Atlaskit collaboration approach, it is, I think, proprietary. The source code is not available, I think. I'm not sure.
Fabian: - I haven't seen it. I've searched everything on collaboration that's out there on the internet. There's even some prototypes from The New York Times that still can be found. There's a five-year-old ProseMirror version if someone will dig into history.
Preston:
- Absolutely. Well, we are starting to run out of time, but I do want to give some opportunity to talk about some of the more interesting aspects here. By the way, what sort of additions have you made to ProseMirror? Just very, very quickly. I know, Fabian, you've done some work on this.
Fabian:
- One of the important things, and I've already talked a little bit about that with how I explained the document models is reintegrating ProseMirror with Drupal. Now someone says, well, but yeah, Drupal supports many editors, but yes, only those of the old generation. So what we are now talking about is kind of we have these JavaScript mega beasts that are usually run with Node. And they are coming to the old giants of PHP, like old not in terms of being very old, but Google has been around 20 years and it's traditional PHP-based. It's just base HTML that you store in a database. And you have this ProseMirror and it has this JSON model. And how you usually would do that is you would take this JSON, run it through Node. Node would launch a little instance of the editor then would display it, and then the webpage would be delivered. We cannot do that because we are basically bridging this old generation of editors with the new generation of editors. And that's very, very interesting because when I was starting up with that, the React developers were like, why do you want to output HTML? Why do we need that? And the Drupal developers were like, JSON? Why would we put JSON in the database? We are storing HTML, we are storing JSON. We're storing both in the database. We're storing the HTML only kind of like a cache for display purposes. That's what we will be displaying to the user. And the JSON is what we then feed again into ProseMirror, or Atlaskit, or our custom editor. In this case, for loading up the same state as it was before. So, that's very important in that so we don't need to store to HTML, load the HTML again, store it again, and convert it back and forth where we could be losing data where it's prone, but we are storing the document model of ProseMirror directly in the database. We are storing also the HTML so Drupal can display that. That was a little bit of a challenge. A challenge that the whole of Drupal agents somewhere or another will also face because now we're going, kind of like with Drupal itself, with Drupal core, into this direction of this new generation of editors. So, that's a lot of challenges, and I hope we can speak in more detail about that at some other point. But it's really interesting. And then also, just loading this whole React, and then you have a frontend which is still jQuery-based, dramatic person, and AJAX-based, and it's this traditional how Drupal used to work in that. But now this new framework comes and now you want your @mentions but also working with some traditional Drupal comments, and you have to combine those two worlds. And that's very, very interesting.
Preston: - So, it seems that... Oh, sorry, go ahead.
Fabian: - There's one part that we did that was really exciting for me besides all of those mentions, collapsers, sections, and the collaboration and shared editing.
Preston: - Well, unfortunately we are out of time. I did want to get to talking about the integrations but clearly we will have to save that for another time. I just wanted to say thank you so much to all of you in the audience for watching or listening to the live Team Talk. For all of the things that you heard in this call, in this webinar, things like ProseMirror, things like Yjs, things like Draft.js, all of these things, we're gonna have links with all of these technologies that you can take a look at. By the way, please don't forget to check out our previous webinar, the inaugural Tag Team Talk about shared editing, collaborative editing. And by the way, if you're interested in learning about a particular area or a certain topic, please feel free to reach out to us and the team at tagteamtalks@tag1consulting.com. I want to give a big thank you to our guests today. First and foremost, Nick Graf, our senior software engineer, based in Austria. Fabian Franz, senior technical architect and performance lead. And Kevin Jahns, realtime collaboration systems lead and creator of Yjs. And of course, the managing director of Tag1, Michael Meyers. This is Preston So. Thank you all so much. And until next time, take care.
--------- Photo by Natalia Y on Unsplash