A Deep Dive Into Real Time Collaborative Editing Solutions - TagTeamTalk #001

What is real-time collaborative editing, and what are some of the most compelling technologies available in the space? In the inaugural Tag Team Talk, hosted by Preston So (Contributing Editor, Tag1 Consulting), we conduct a wide-ranging discussion about both the business prerogatives and technical ins-and-outs of real-time collaborative editing and its landscape today, with our guests Kevin Jahns (creator of Yjs and collaborative editing expert at Tag1 Consulting), Fabian Franz (Senior Technical Architect and Performance Lead, Tag1 Consulting), and Michael Meyers (Managing Director, Tag1 Consulting). In this talk, we explore collaborative editing, diving into how it works and some of the challenges borne by shared editing. Through the lens of Yjs, a real-time collaboration framework that supports not just text but also collaborating on drawings and 3-D models, we take a look at Operational Transformation (OT) and how implementing Conflict-free Replicated Data Types (CRDT) drives decentralized server approaches in collaborative editing and supports more robust distributed applications with true real-time support.

For all of Tag1's Yjs content, see Yjs - Add real-time collaboration to any application.

Text Transcript

- Hello, good morning or good evening, wherever you are. And welcome to the first ever Tag1 Team Talk. This is Preston So speaking to you loud and clear from New York City. I'm the contributing editor to Tag1 Consulting. And it's my pleasure today to jump into a deep dive into realtime collaboration tools. I'm joined by three guests today. First and foremost, I want to introduce my partner in crime Michael Meyers, the managing director at Tag1 Consulting. I'm also joined by two folks from around the globe. We've got Fabian Franz, senior technical architect and performance lead, as well as Kevin Jahns, creator of Yjs, a key contributor to realtime collaboration projects, and a maintainer of open source projects. So, I wanted to start off by introducing ourselves one by one, and then we'll jump into what Tag1 Consulting's all about and get into some of these meaty topics we've got for today. My name is Preston. I'm the principal product manager at GatsbyJS as well as contributing editor to Tag1 Consulting. Mike, you wanna go next?

- Sure. Mike Meyers, managing director of Tag1 Consulting. I have 20 years of experience working in technology, managing and running teams. I've been working with Tag1 first as a client for over a decade, and joined the team about two years ago.

- Hi, so, I'm Kevin Jahns. I live in Berlin, Germany. I'm the creator of Yjs open source framework for realtime collaborative editing. Because of that, I got many interesting opportunities to work for really cool, interesting companies on realtime editing. They mainly use my framework and need feedback or help to deliver a great product. I'm currently really happy to work for Tag1 and one of the Fortune 150 companies to make that happen.

- Thanks Kevin, pleasure to have you with us. And Fabian?

- Hey, my name is Fabian Franz. And I'm at Tag1, as you already said. I'm a senior technical architect. I really enjoy architecting large websites and making them really fast. And I'm so excited about realtime collaboration because I think realtime kind of is the future of the web. But we also did a DrupalCon presentation slightly related to that topic, in Amsterdam. And besides that, I'm a Drupal core 7 maintainer right now, and working with Tag1 is just fun.

- And we've known each other for a long time, Fabian. Well, perfect. I think first thing we want to do, though, is set the stage a little bit. What exactly is Tag1, and why are we all here in this room? From what I understand, Mike, you all are the emergency support and rescue, and performance and security experts. Can you tell us a little bit about Tag1 Consulting and what you're all about?

- Definitely. We're the company you turn to when you have difficult and challenging problems to solve. We build mission critical, highly scalable, highly available and secure applications for companies like Symantec. We've worked for them for over a decade. We manage and built their infrastructure work and oversee their agency partners, setting architecture design and doing manual code reviews for security and quality. What we're gonna talk about today is a project that we're working on for a top 50 Fortune company, Fortune 50 company. They are rebuilding their intranet, and realtime collaboration is a key component of it. And frankly, I can't believe that realtime collaboration isn't a default feature in every online application, certainly every CMS. When I think about my daily workflow, I'm constantly working in something like Google Docs, collaborating with the team in realtime. And I know a lot of people, we're talking to another client about a project and they do all of their work in Google Docs and then just pump it into their Django CMS. And so, we really believe that this is the future of a lot of applications, and we're excited to be working on this particular project, so we wanted to talk to everyone about it because it's got some awesome tech behind it.

- Absolutely, I agree. I think that realtime collaboration is one of those intractable problems. It's not quite on the level of some of the key problems in computer science, but it definitely is a very, very, a large problem set that actually hasn't been solved completely across the board. Google Docs obviously has solved a lot of those issues. But I want to dig a little bit more into why it is that we're all on this call, why it is that we're so interested in realtime collaboration. Obviously it's something that is important to all of us. But can you tell us more about this Fortune 50 company and what some of their requirements are, and what exactly realtime collaboration means to them?

- Sure. It's a gargantuan project, multiyear project. It's used by 20,000 active users at any one time, across 200 countries, in well over a dozen different languages. It interfaces with a large number of third-party tools and systems, from centralized authentication access control through to Slack integration, as well as integration with other third-party tools and a number of internal proprietary tools. The idea is that we live in a world where you want to integrate the best technology for the job as opposed to reinvent the wheel. And so, what this... Their new generation of their intranet is to really pull in and integrate all of these different systems into one place. Because the downside of integrating all these different applications is that it can be hard to collaborate and find things if you have files in Box, if you have documents in Quip, if you have communications in Slack. All these disparate systems have different organizational structures, typically are run by different groups and departments. The idea is that the intranet will be the central hub that pulls together all these tools and information, helps you find what you need, but also provides that in a universal search and collaborative layer on top of it as sort of like the metasystem where you can talk about everything from, and track those tasks and schedules, to what your roadmaps and sprint reports are for your particular initiative.

- There's actually, and I recognized a Dilbert comic about it, where he's like, I need this document on my desk tomorrow, the boss says. And he's like, would you like it via Dropbox, via Box, via mail, via Slack, via whatever, via Skype?

- That's right. Sometimes I work with a friend and we don't have an organization to work under with. And I sometimes wonder how can I send a large file, like just 100 MB, to my friend. It's really hard right now.

- Yeah, it is really difficult. And I think this really calls out one of the things that you actually alluded to earlier, Mike, which was the fact that we have a lot of folks who are using CMS's as part of their daily workflows, but they need a realtime collaboration tool to bring it all together. I think the fact that we've heard from a lot of folks that they use Google Docs before copy and pasting over to a CMS or over to their desired tool shows that this is really the nexus of where all of these interactions occur. And so, I guess I'm curious just to dive into some of the business requirements just briefly before we get into the technology. I know that's where we definitely want to spend a lot of time. But why is it that something like Google Docs doesn't fit the bill for this use case?

- I can't talk too much about the company itself. But for business reasons, they are unable to use Google Docs. They're a competitor company and they can't have highly sensitive, mission critical information on third-party servers. This entire application is air gapped, highly secure. They have very different levels of projects, from public to ultra secure. There's even separation of data and communications. So, things that are for the highly secure projects are stored on different servers and the realtime communication goes through its own system. Everything from physical separation of data and information to air gap. And while they are able to use... Or sorry, not able to use Google Docs, the other reason is that they want this highly integrated into the system. A third-party collaboration tool, whether it be Slack, or Quip, or Google Docs, or something that facilitates that collaboration, has the same challenging problem that we talked about earlier. And so, by integrating this directly into their intranet it's a core feature. And I should also mention that they want to go well beyond text editing. We're working on collaborative drawing, for example, so that you could have whiteboards. In the future you could have your agile Kanban boards show up on this system even though they're coming from a third-party tool via APIs. You can see that information. Our goal isn't to replicate all of these systems in the intranet, but to present you with the most mission critical information that you need at a glance, and to then link you into these systems. In the case of collaborative editing, it's such a core feature to enable teams to work together that it's built in.

- Also, one of the challenges with using something like Google Docs always is access. Being a large company, obviously they have a central directory service where everything is managed and accessed, and you now need to enable this third-party system this access. That's pretty challenging because they're mostly scaled for a few users, in that you invite your team, and then you work with them, collaborate with them on that. But then you need to put it back into the CMS and there's this kind of gap between your workflow so you're always like, now you've published a version, but now some more changes need to be done. Who will synchronize that, who is dealing with that, et cetera. It's basically two systems you need to work with. Even for our workflows where Tag1 had a Drupal watchdog before, it was challenging, and kind of what is the source truth once you get to a certain point in that.

- Absolutely. I think the notion of something like realtime collaboration being built in, being an intrinsic part of an end-to-end system, is a kind of key feature. But I think what you just alluded to in terms of permissioning, and having to figure out, having to reconcile user roles and permissions across two very different systems can be very challenging. And having the ability to do that in a way that is really integrated with the overarching system I think makes a lot of sense. Let's go a little bit away from the business requirements and let's dig into a little bit of the main concepts behind realtime collaboration. I know that all of us on this webinar and podcast all know some of the basic components. But just so we can bring it down to the level of what some of the core fundamentals are, how does shared editing exactly work? How does this idea of realtime collaboration actually begin from the standpoint of clients, communication, concurrency? Where do we start with? What are the main elements that are involved?

- I do think we start with a very basic, just what is shared editing in general. And many companies also use already something like Etherpad where you can just have some text and collaborate it. I know we also used it for the Drupal community when we had challenging things to solve just to facilitate note keeping a little bit in that. The most basic thing about shared editing is really just text. It's not formatted text like Google Docs or something. It's really just text. And this is very simple. So, you have an example of like, for example, I have the text written, "This is some text." And now Michael wants to make it, "This is some nice text." But I want to write a little intro, so I wrote, "Hello Preston, this is some text." And now you need to know a little bit about how editors work, and an editor needs to know how this works. My, "Hello," would be inserted at position zero, so at the start. But Michael's, "Nice," would be inserted at position 12. But now, if I write before him and the editor still thinks he should put it in at position 12, then it's wrong, because we kinda... The positions changed because I've added some text, so editing has shifted a little bit. And the idea of CRDTs here is that instead of having this position-based system, just on a very, very basic level, they are very more complicated but just as a layman's explanation, is that for every character, you are giving it an identifier. And this identifier is also a little bit how a human would reduce this conflict, resolve this conflict. Because instead of saying, hey, insert this, "Nice," at position 12, you're just saying insert it after, "Some." And that's basically the idea, kind of. And because of that, however the text changes, Michael's, "Nice," will always be inserted after the, "Some." That's kind of how you can think about how you get shared editing to work on a very, very basic level.

- Let's talk a little bit about the communication. I think that that was a very, very great explanation of how concurrency would function in this kind of environment. I'm curious, though, there's a notion of a difference in communication between how some of the traditional collaborative tools have worked in the past and how, let's say Yjs or some of the more modern tools do it today. I know that, for example, in the past the way that people would do this kind of collaboration would be through a server and a client. A centralized server that houses all of the information about what's changing and manages all of that, as you said. But one of the key differences that I noticed about Yjs is that it's focusing on a more peer-to-peer, a more decentralized approach. Do you want to talk more about that, Fabian or Kevin? What does that mean to somebody who is evaluating some of these solutions?

- The classical approach is like, Google Docs in general, operational transformation, it mostly works in the client-server environment. So you have a central point where you do all the transformations between the document updates. For example, a user inserts something at position zero and another user inserts another character at position zero. The server decides how the document looks like at the end and does the transformation before sending it to the other peers. So there's like a limited concurrency because there's only concurrency between the server and the client. And, like, it's pretty unfair because their operational transformation approach is they do work peer-to-peer, but they have a lot of overhead, a lot of metadata. In CRDTs in general, you don't need a central point of transformation. Like, all CRDTs, they allow for commutative operations. So it doesn't matter in which order your changes come in. The document will look the same for every peer as long as all the peers exchange all the document updates. And that's a really cool feature. So, you don't rely on a central server anymore, and you can actually scale your server environment. You can do really cool things with that. Most people think, oh, peer-to-peer, you have peers communicating directly with each other, and I am a huge fan about that. But especially for businesses, it makes sense to have still a server environment. And here, the advantage of Yjs or CRDTs in general is that you can scale your servers indefinitely. If you know that Google Docs is limited to a limited number of users, I think the limit of users who can concurrently edit the document is set to about 15 people. And after that you will just see a copy of some snapshot, and maybe it gets updated. I haven't looked into it for quite some time, but I know there's a limit. Which is kind of strange. The problem here is that you have centrality and you need to make sure that you never lose document updates because the centrality is also your central point of failure. So if this point, like if this server burns down, your hard disk, your document is gone. You can never merge again, you can never restore that document. But in peer-to-peer or decentralized systems, well, it doesn't matter if one system burns down. You still have another one.

- I think that single point of failure is a really key and worthy of emphasizing aspect here. Which is that one of the things that is a very key concern for enterprises today, and just companies in general, is the notion of having the ability to keep things decentralized. If you have that central point of failure, everything falls over, you don't have access to anything. And the notion, I think, of peer-to-peer, decentralized, shared editing, allows for local copies of those documents to be on every single node, let's say, of every single person who's working on the document.

- Yeah.

- Yeah, go ahead, Fabian.

- Even if it's very different from how, for example, something like Git works, because it has very different properties, you can use the same examples as advantages. For example, one of the nice examples that is always quoted with Git is some developers can work on a plane together. They can collaborate on some code on the plane together because everyone has a whole repository of all changes. And that's kind of the same with Yjs, to some extent. You can optimize it to not have solo history, but you can have solo history, so two people that happen to be on the same flight could realtime collaborate on that document and later send it back to server. But they would not need a central server component. They could just do it. They could put work on the plane. And I think that's a really cool feature. And not just two, it could be a whole company, like 50 people finishing a last minute document collaboratively. Internet on planes has gotten better, yes, but it would be really bad if your Google Docs suddenly while you're on that plane. With Yjs, you just have the guarantee that your personal server works and you can finish your last minute document.

- It was pretty amazing, we actually saw this in action, unintentionally. We were doing a demo to key stakeholders. We had just integrated the realtime collaborative system which we kind of built independently at first, with Drupal, the core of the internet. And we were doing a demo of the system in action completely in development environments. We're pre-alpha. And during this demo, the server failed. Yet the collaborative demo just kept going and working perfectly because it was peer-to-peer in the backend. And the infrastructure engineer on the call was able to get the server back online, and it was just absolutely seamless. So it was really cool. All of us were like, my god, we didn't intend to demo that. That was amazing.

- And I think that, I think Fabian, you mentioned something that was really key there, which is that idea of a spotty connection. Obviously people working on flights. This case that you just described, Mike, as well is a very good example of this. This kind of approach that focuses on the notion that everyone has a local copy, just as you said, with Git-based approaches as well, this is the kind of thing that even if you're in, let's say the middle of nowhere and have a really horrible 3G connection you can still get the editing capabilities, and get that sync going, and make sure that things stay up to date. I think it's a very, very key value proposition. I want to jump back into Yjs itself because I think that a lot of people are really interested in operational transformation. A lot of people are interested in what exactly CRDT is, and all of those things. But first let's talk about a very key issue in collaborative editing that I think really uses a little bit of discussion. And that's the notion of an edit history. One of the biggest challenges that all content, all people working in content governance and content strategy have is the ability to distinguish between different undo histories. How does undo really work in the context of shared editing versus single editors? And how exactly does that work from a technical standpoint? Is there a global state, what's driving that state? How do you reconcile some of these things? We can talk about it from the perspective of Yjs or other tools as well.

- Man, undo/redo, it's a really, really hard problem, especially in CRDTs. In operational transformation, this problem is not that hard. You can just do undo/redo your own operations. You can just do the transformations in the document history. But you don't really have that history in Yjs, or in CRDTs because it just, it works differently. It's not really operations that you put in a linear log. It's more like operational set are in some kind of tree, and you can't really decide, okay, where do I need to start undoing. So the thing in Yjs is... Yeah, so, the way I implement it actually is in this tree I give a path of the undo/redo operations. So I basically say, this is the kind of state that you need to remove when you hit undo, and this is the kind of state that you need to add when you hit undo. And this is basically how I manage it. It's kind of complicated without deep diving into how Yjs works. But yeah, it's mostly a solved problem at this point. So, the undo/redo thing, it works on linear text really, really well. And there's great progress on structured documents, like on ProseMirror, which is, it's one of the editors that Yjs supports. So, there you basically have this structured document, a paragraph which has a table and the table has some lists maybe, and there you type and hit undo. You really need a good sense of what to undo and what the user expects when you hit undo/redo. Yeah, there's great progress. And the undo/redo implementation is configurable. I'm not saying that it's done yet. There's still users reporting, "Oh, that's weird," because it's pretty new, undo/redo on structured documents.

- Just to show how difficult undo/redo is, you can do some great experiments with other out-of-the-box solutions like Google Docs. You can have lots fun. Also with something like conflicting things, like Google Docs has some offline support, and I've taken the liberty to just test some scenarios. Like, you will have a paragraph, a long line, and do an enter break in the middle, and how does the system react? And it is really cool to just try out this, like, perfect product, built on knowledge of giants with Google Wave and all the technological and theoretical things, and then you try some undo/redo scenarios, and you get some really weird results even in the top notch product on the market right now. It's really interesting.

- Yeah, I think the notion of, like, what happens when you get a merge conflict or a sync conflict in Google Docs. It's always a fun experiment. It's rare that I get those messages these days, but it's always an interesting experiment. I do want to go back to something you just mentioned though, Kevin. And I do want to dwell a little bit on some of those really nitty gritty features of Yjs and really do the deep dive. But I'm curious, you just mentioned that the undo/redo behavior is actually configurable in Yjs. Can you talk a little bit about how that is, or what sorts of configuration can be expected?

- Oh yeah. The thing is, in Yjs you have... Yjs basically, well, my idea of Yjs is that you can see it as a shared type system. So you can create shared data types, something like an array, or a map with a key-value store. These data types, they work concurrently. So one user can manipulate them and the other one receives the updates, and then they sync. This is how I see Yjs. And then there are bindings to editors like ProseMirror, and CodeMirror, and many others. And often you have this big Yjs structure, and it may be a structure of several documents. So, when many users, or when you are working on several documents at the same time, and then you hit undo, what do you expect to happen? Does it also undo something from other documents? I don't think so. In my mind, I work on one document, I only undo the changes of that document. So this is what I mean of configure it, being able to configure it. You can specify what can be undone by your undo manager. There can be several undo managers, several document histories, for your local user. And you can specify what can happen and what cannot happen. And there are two mentions in Yjs. It's mainly you have a scope to a specific data type. For example, this undo manager can only undo stuff on this document. And then you have the scope also of... So, for example, what happens, when I created a paragraph, you created this big chunk of text in that paragraph but I didn't know about that, and then I hit undo? Can I undo the creation of that paragraph or not? Most users, as I found out, would say no, you should not delete content if you didn't create it. So in this case, you are not able to undo the changes of other users because sometimes these changes are intertwined. And the challenge here is really to figure out what is it what users expect when you hit undo.

- That's very interesting. I think that that really digs at, I think, the central issue of undo/redo, which is that people have different expectations of it. And having that as a configurable element I think is a very, very compelling idea. Well, okay, so let's dig out of undo history. Oh, go ahead. Sorry, Fabian.

- And there's also one of the key points why we think that CMS's itself should have the collaborative technology, and Drupal should have it out-of-the-box as a contributed module, Azure CMS should have it out-of-the-box. It should be really as simple as install a JavaScript library, like a plus module, and maybe a little server component if you don't want peer-to-peer. But then the centralized point here is that every client, every user, has their own expectations, they have their own challenges, they have their own things. And also, also all the editor space, even going to add a little bit of what we wanna go in more detail maybe in future episodes, they are no longer shipping out-of-the-box editors. They are shipping editor toolkits so every CMS can build their own editor to their needs. Every client, every project, can build their own editor. And I think that's a very, very key point to our current ecosystem of CMS's. And that someone else might need completely different undo managers than I need or this project needs. And that's also the beauty of open source. You can just take it, refine it, extend it, and do it. That's so cool with Yjs being open source that you just have this ability to do all these cool things.

- I'm not sure if we have the liberty to do this, but can we dig into a few of these potential scenarios where having this kind of differentiated configuration would be useful? Fabian, I think you mentioned a very interesting idea, which is that different users want to have different approaches to how they edit. How have you both seen this shake out in terms of the things you've tried, experiments you've tried? Or Mike, has this come up in terms of use cases? What sorts of things have you all seen in the real world that relate to this idea of having completely independent experiences?

- So basically, top 50 Fortune client it is customizability is key. It's very important that they have, for example in this case, their own editor which is exactly working to their needs. And the collaborative functionality is everything like you're expecting from Google Docs like just comments and later, even track changes, still working on that, pretty challenging. That's all very key in that. And it's important that, for example, if you use a technology like React upon which you can build your editor... Think of Confluence which is built upon Atlaskit. And Atlaskit is, by the way, also open source and one of the components we're using here as base. Then you can extend it, and you can build your own and you can customize it. That was really a key, central point to being able to not be stuck with some proprietary solution, or be stuck with some out-of-the-box solution where you cannot define anything, where you just get sent a black box and then you have to work with it. Because then if you need to change to the undo thing, well, yeah, you can pay Windows for it, obviously, but it's really out of your control. And here you can work directly with , but even later you can maintain it with a different team or whatever because it's accessible code. Another advantage of open source, basically. But yeah, the extendability, and being able to, for example, also define the server component. In this case, a server component is needed even though peer-to-peer would work and works well within the same browser or within even cross-browser with some tricks. Because you want, for example, authentication. If you store confidential data in a shared editing thing, you don't just want to be able to just access the server and see it, but really you want to... Which is usually a Node server, by the way. But really, you want to have authentication tokens like you're used from different APIs where you can secure your server. Then you can say, yeah, this operation is allowed or this operation is even not allowed. Even being able, as Yjs messages, even if it's not kind of like messages it's still some transformation sent over the wire. And then you could deep inspect it, and can say, hey, this is not allowed. This document was not touched for 300 days or whatever, and now someone is deleting all the content? Maybe deny that. Or keep a snapshot before that. And that's also so... So here, central server is nice and needed because you want to have that control but it gives us this flexibility in that, and you don't get that flexibility if you work just with a black box.

- Control is something that's a key theme of this project, this organization. Why we don't want to reinvent the wheel and rebuild certain awesome third-party technologies, this client of ours has repeatedly been let down by vendors that have made commitments to add certain features or do certain things over time. And one of the reasons that they're rebuilding this system and investing in these kinds of technologies is that the business cost of not being in control of sort of core technologies is huge. And so, relying on open source projects, being able to own and manage this code internally for their needs is critically important. This is gonna be a system that's gonna be around for 5+ years. The current system has been in place for a little over seven. And so, a key recurring theme is we need to be able to have long-term maintenance and control over key aspects of our technology.

- Yeah, and I think... I'm sorry, go ahead, Kevin.

- All right. I just wanted to add, one of the things that a lot of people appreciate when I talk to people who use Yjs is that you can easily use Yjs on top of your existing communication protocol. So there are many existing projects that want to integrate collaboration into their system, and they already have some kind of WebSocket connection or long polling setup, and they want to use that system. And for good reason. They don't want to change their whole infrastructure, add another communication layer like some proprietary WebSocket communication protocol, and build on that. They want to integrate Yjs into their existing protocol. That's something that you can easily do with Yjs. And this is also something that Fabian talked about just now. I completely agree with that. I didn't think about it when I implemented like that, but it just came up that it is really well appreciated. And because of that, I put everything into separate modules. Yjs is split up into like 20 modules right now. Once you build a system, you basically say, okay, how do I communicate? I use this existing module, or I can rewrite my own module on top of the Yjs code, or just on top of the documentation that you have. And if you want to support your own editor it's so easy because the editor support is not baked into Yjs. It's not just built for one thing, it's built for everything. And that makes it incredibly difficult to do, but I think it's a really nice concept.

- Yeah. And speaking to that, the editor support, if you have textareas somewhere and you want to make collaborative, you can do that right now. There's a translator for a rich text area, like the contenteditable, or just any textarea. You can just take it, put Yjs on it. And there's also a nice demo site. There will be some post information. We'll link to that with some links in that. There's a really cool, there's even two demo sites. One is really showing like ProseMirror, Quill, and even Atlaskit, the whole Confluence experience in that. But there's also shared editing for a nice thing. There's even a 3D modeling demo baked in together with 3D modeling. It's insane, it's really insane. Also drawing. It's, like, really cool. The possibilities are so endless. It's so nice that it's so framework agnostic. Really not just editors and really not just one editor. But really, if you have a textarea, you can use Yjs, it will be collaborative, it works. And even for older things, if someone wanted to invest in that CKEditor 4, it would be possible, in theory, to make that collaborative. People wouldn't even need to operate newer technologies. It would need work, investment, et cetera, of course, but it's possible.

- Yeah, I think this notion of flexibility and customizability, but also especially this notion of pluggability, where you can insert Yjs into any situation and it works. I think also the flexibility. Fabian, you mentioned earlier that in certain cases you do want to have a server component that acts as the safety kind of mechanism. But you might not want one, and Yjs leaves that option open as well. And I think just the notion of being able to insert it agnostically anywhere you want is a very, very key characteristic. I think one of the key characteristics that we identified a little bit earlier but we haven't really dwelled on, though, is one that's very interesting to me. Which is that you can use Yjs for things like text, you can use Yjs for textareas and contenteditable, but what about drawings and 3D modeling? I know, Kevin, you've sort of framed Yjs as being for more than just text. Can you talk a little bit about the drawing capabilities? What does collaborative drawing mean, and how does Yjs fit into that?

- Yeah, definitely. This all comes from the idea that Yjs is not just for specific applications, but it's just a framework for shared data types. You can build any application on data types because, well, that's what we usually do as developers. We have these key data structures, especially data. In JavaScript we have only two or three main data structures, which is arrays and maps. You can build your own data structures on top of that and they're abstractions, but basically you just have arrays and maps. And maybe set is also something that, well, I really like the idea of having a set too. And you have the same capabilities in Yjs but the difference is, these data structures or data types, they are collaborative, they are shared, so when you do an edit to this data type the change is transmitted to all the other peers automatically, and they sync, and then you get updates of what changed. And you can design your application like that. Just use the shared data types and build your application. And drawing was something that is really, really easy to implement on top of data types, or shared data types. A line is basically just a list, an array of vectors. So, this is what is happening in the drawing demo. When you start drawing, you have a map, you insert a line to that map, and then you start drawing. It's really easy. And then you can maybe configure it by adding some options to the map, or something to color, who created the line, all this information. You can just add it to the shared data structure. And this is also how the 3D modeling is created. It's really basic, but it's really cool because it shows that everything you do, like rotating the 3D object, the rotation is a part of the shared data type. You can add annotations and these annotations are just X, Y, Z values, and you add this to the shared data structure. And just like this you can build amazing applications, just on top of this idea.

- Yeah, I was thinking about the classic React example, the to-do list. And the to-do list basically, the results are often shown for Redux data stores like transformations, et cetera. And now put this final array that you put your data in, or this kind of map, probably an array in this case. Put that in the Yjs data structure and it's automatic. It's kind of almost automatically collaborative. That's just great.

- Is one of these in particular harder than the others? Is collaborative text editing actually harder than drawing?

- Collaborative text editing, like, I want to distinguish between text editing and rich text editing. Because text editing is pretty easy. It's harder than having a 3D model, in my opinion. From my perspective as a developer of Yjs, it is harder because text editing, you need to optimize that a lot to make it performant and don't block the thread. You want to be able to insert, like, a megabyte of text into your data structure. And that's not always easy. First of all, because of the time it takes to send to the other peers, but also the time it takes to parse that operation, that change. So, text data structure is heavily optimized in Yjs, and that's why it's performant. For you, it's as easy as the array, as using the array data structure. Rich text on the other hand, it's a bit weird because you can either have structured documents. This is what I think of in ProseMirror as like, you have a paragraph, inside that you have a table, and so on. And then you have also formatting attributes to your text. So, when you write the text, "Hello world," and you want to make, "world," bold, you don't remove the bold text and add some text, tags like in HTML, around this word, "world." You want to assign attributes to this text. And this is also possible in Yjs. It's like this rich text notion from the classical Windows. I think they developed the term rich text. You assign attributes to text. This is also one of the problems here. And like, as soon as you realize that this is going on, you can either have structured documents, or rich text documents, or both combined. In ProseMirror, they're kind of both combined. You have marks, so you can assign properties to it, to text. And as soon as you realize what's going on here, it's fairly easy to build applications on top of that. But building editor support, that's a whole different level for if you build a structured editor support, for example for ProseMirror. It was really, really hard to get right.

- Yeah. And speaking of performance for inserting, we did a test. And if you take a really, really long document, you paste it 10 times into Google Docs, it takes longer and longer. It takes around seven seconds. And with Yjs and CRDTs, it's instant. It's really, it's really just instant. I was astonished. I also tested some other things, which I don't name to not shame. But there I was even able to freeze, to completely freeze the collaborative editor, and it was not reacting anymore after a while, and undo . It's just not a pleasant experience. It was so nice to see this just working so well with Yjs. With one of the key points where I was able to present, with stakeholders that were evaluating the technology on the client side with me to say, hey, this is really working great in practice. Just try pasting a big document. Now try the same in Google Docs. It's like a difference of night and day.

- Absolutely. Yeah, and I think one of the things that's interesting is if you look at Yjs in relation to some of the other tools that are out there and available, I know that, for example one of the, some of the very common tools people use out there are things like CKEditor 5, ProseMirror collab, as well as Draft.js. But one of the things I know is that there are certain features that are lacking. I know that you don't want to name and shame, Fabian. But I'm curious, what makes Yjs superior? One of the things I know, for example, that Yjs does better is one thing you mentioned earlier, Kevin, around content annotations, being able to directly apply those annotations. What are some other examples of how Yjs is better than some of these other solutions and stacks like ShareDB, Automerge, the CKSource service? What are some of the things that you both found were either better in Yjs, or lacking in others, or things that you noticed?

- First of all, just to get it out of the picture, the CKSource solution unfortunately is proprietary. It's a server black box. You have to pay for it. Which is fine, that's fine. But as I've already outlined a lot on this call, open source is just better. Because, well, I mean, Drupal is open source, many technologies are open source, and those open source technologies, they thrive, because companies invest in them, they mature, and everyone can use them, and that's so important. That puts out the proprietary solutions. They might be useful for the one where each project of that, but they're not useful, in my mind, to the larger community in that. And for Automerge, ShareDB, I'll let Kevin speak. expert.

- Yeah. So, about these two projects, ShareDB, it was always my goal to be as good as ShareDB. It's a really cool project. And I was inspired a lot of the features they have, because they also have the notion that you can just manipulate your data and then everyone gets synced up. And I love that idea. At the time when I created Yjs, they didn't support, for example, objects as key values or so. And this was like, okay, it can't be so hard to implement that. I also want to make it peer-to-peer. So, this is why I created Yjs. And it only took me six years to do that, but that's fine. So, I think Yjs against ShareDB, they're both great projects, but ShareDB is based on operational transformation which is centralized, and I always loved the idea of having a decentralized system. And Automerge, also a really cool project. I really like the maintainer of that project. He is really active in the research community, and he's a lot more credible than I am in the papers he created. He is a really good writer. And if you get the chance, and are interested in CRDTs, you should definitely check out one of his talks about CRDTs because he really explains it well how it works. But now against Automerge, right now, Automerge is not as performant as Yjs. That's just what I want to say there. Yjs is really focused on shared text editing. And Automerge also supports text editing, but it's not as fast. I created some benchmarks. Maybe we can link that too. You can also find it on the GitHub repository of Yjs. But yeah, these are the main reasons against that. It still needs to be seen which algorithm is better. But the thing is, in Yjs I had more time to create Yjs and I implemented a lot of optimizations especially for shared text editing.

- Yeah, and it's also a very important point in if you want to do a collaborative system for application with a JSON structure, try out Automerge, try out Yjs. We are open source. There's always a good solution for your project that you need. But if you want to do text editing then Yjs gives you this undo manager. It gives you these functionalities for rich text. It gives you this control. It gives you this basic server component if you need. With Automerge, you build everything your own. You can do that, it's fine. People have done that with certain editors. But it's really Yjs gives you a headstart and a framework to work with shared editors here especially.

- Yeah, and this is really interesting. I think one of the things... By the way, just to help our viewers and our listeners, we keep on throwing this CRDT acronym around. It's actually one of the big reasons why I think Yjs is so compelling. CRDT, by the way, stands for commutative replicated data type. You can look at it on Wikipedia in the operational transformation article, very, very useful. But I think just to dig into CRDT a little bit briefly, I think one of the really key aspects of Yjs that we've obviously been touching on here and there is the fact that because of this focus on data types it's very powerful for rich text editing, more so than some of the, especially for those who need more than just the plain text editing feature. But I think this is actually just one example of some of the really interesting features in Yjs. One of the things that I found really interesting is because of that kind of agnosticism and because of that focus on that kind of lower level, we actually find that other things are possible with Yjs, like using multiple document formats. So you can use rich text, you can use markdown, you can use HTML, anything that's kind of a parsable AST. What I'm curious though is that there is a topic very near and dear to my heart which I know that Kevin, you focused on, which is actually the notion of accessibility. So I'm curious, how exactly does accessibility work in the context of realtime collaboration for Yjs? Especially given the fact that rich text editing, realtime collaboration, both very, very difficult things to do in an accessible way. Are you using things like ARIA labels? What are your thoughts on accessibility with realtime collaboration?

- Accessibility is firstly an issue for the editors. Yjs is not really concerned about accessibility because it's not really part of the framework. But if the editor supports accessibility then it's baked into Yjs. By the way... No, actually that's all I want to say about that. Most editors nowadays are really accessible so there's not a lot of concern there. I'm also not an expert in accessibility, but I'm also really concerned about what happens when you hit undo/redo, for example. Which is, by the way, not working in Google Docs or in most editors. Try hitting Edit and then Undo in Google Docs. It doesn't work. And I'll figure out why.

- Very interesting. Wow.

- But maybe this is part of the discussion when we talk about editor support, or which editor we choose, Tag1, and for the company that we contract for.

- We'll do a followup talk on that. I think that the whole editor component, we did a ton of research. So maybe we'll do a Tag talk next on the whole editor component and how we ended up with ProseMirror and the integration of all that.

- Yeah, because that's an area I'd love to dig into in terms of ProseMirror's capability. CKEditor also has really great accessibility features. But how that relationship comes together, how Yjs really integrates with some of these editors and how those features get exposed, that's a really interesting topic that I know we're gonna have to save for next time. In these last few minutes here... We've covered a lot of ground here. We've covered realtime collaboration. We've covered some of the problems with concurrency in these editing tools. We've also talked about CRDT from the very, very high level standpoint. I'm curious now, I think one of the things people are interested in is, well, what is the future of Yjs, Kevin? What exactly do the next couple years hold for Yjs? What are some of your goals in the future, moving forward?

- My goals. My goal is to create editor support for all major editors out there right now. There's currently editor support for code editors like Ace, and CodeMirror, and there's rich text editors, for example ProseMirror and Quill support. There are many interesting additions to Yjs, and I want to increase that number. I want a lot of people using that technology. Because if you use Yjs as the entry point for your data model you can have different text editors. For example, you can have CodeMirror and Ace, like one user uses that and the other uses a different editor, and that's a really interesting idea for me. The other thing is, what I'm really interested in is real decentralized systems. And there's mainly the dotProject and the IPFS project, and building on top of that system, like each centralized system, wow, it's so amazing. You can build an application without a central server only having, well, peers, just working stations meshed together and they somehow create an environment where you can store data, and that's very interesting to me.

- I think that is a very, very compelling idea that I'd love to talk more about with you, Kevin. Yeah, the idea of having a completely serverless implementation I think is very interesting. Well, I did want to say that we are out of time. However, I think one of the things I wanted to call out is something, Fabian, you said at the very beginning of this whole broadcast, which is, this should be something that's part of every CMS and online application. We should be building interfaces that are editable. We should be really enabling these content editor workflows. And I think clearly Yjs has the right idea, has the right journey in mind. And I can see, given that Tag1 is focused not just on Drupal but also all of these other technologies, and building things like central Node.js backends for these editors, all of that sort of work really highlights, I think, the notion that realtime collaboration is a very important concern for everybody. Not just developers, but also our content editors and our marketers who are working with us on a daily basis. Any last words about realtime collaboration, Yjs, something you want to leave our viewers and listeners with?

- I think it's just an awesome technology. And really, even repeating myself, it is such a difference if you start using the system, even if we are just in demo mode as we are pre-alpha, to just collaborate with someone within the Drupal scene. It feels so different to being in Google Docs or being isolated because it's where you create your content normally, it's where you work together, it's the user tools. You can even attach a file directly. You don't have to upload it to Google Docs and later upload it to Drupal. You really have the experience in that you can use a media browser, you can use a media browser, your whole media library that's on the CMS, it's not in Google Docs. You select your file, it's interactive, and it's collaborative. Your peers will see it as well. And I think that's just fantastic, and that's why I'm saying realtime systems for editors, but also realtime updates. Like, I made an update, you see that I made an update directly on your screen. That's kind of, in my mind, the future of CMS's and, in a way, also the web.

- And this is intended to be a CMS-independent solution. We look forward to adding this to Django and Wagtail, to WordPress. Every CMS should have this. I'd also say that we just scratched the surface of all of these technologies. I think this is a really interesting conversation so we'll definitely setup some future talks to dig more into the details, whether it's the editor or the underlying tech, to get into the nitty gritty.

- Absolutely. I think that today we've done a very good overview of the what, the how, and the Yjs. And I want to go ahead and wrap things up here. If you have any thoughts on how this show, what you're interested, in certain topics, please feel free to reach out to us. I want to thank our guests today. Fabian Franz, senior technical architect and performance lead at Tag1. Also Kevin Jahns joining us all the way from Berlin, right. The creator of Yjs as well as a key expert and contributor to realtime collaboration. And of course my partner in crime Michael Meyers, managing director at Tag1. Thank you all so much, and we'll see you next time for Tag1 Team Talk. Thank you.

Photo by Van Tay Media on Unsplash

A Deep Dive Into Real Time Collaborative Editing Solutions - TagTeamTalk #001

Michael Meyers

Managing Director

Related content

Text Transcript

More Migration Resources

Performance testing with Gander

Popular content

Popular blogs