Google Docs for code: the best collaborative code editors in 2022

Collaborative code editors let developers write code together in real time, just like Google Docs. This article compares Microsoft Live Share, Code with me, and CodeTogether. I clearly demonstrate the limitations and benefits of each tool, including how it integrates into existing IDEs, end-to-end encryption and pricing. I’ll conclude with recommendations for different use cases, such as coding interviews, or troubleshooting.

Introduction

When Google Docs became mainstream in 2009, it didn’t take long until it was widely adopted, transforming how users work with text documents. As you probably know, Google Docs allows multiple users to edit text documents together in real time. Many other collaborative text editors have emerged since then, such as OnlyOffice or Microsoft Online Office, which I compared in a previous article.

While these text editors are good for text-like documents, they are not well-suited for source code. In this article I’ll present tools tailored for collaboratively editing code. There are two basic categories of tools:

1. Collaborative code editors: one of the developers who has access to the entire, locally-stored code base hosts a collaborative editing session from her IDE. Typically, the collaboration tool offers a IDE plug-in to add this functionality. Once the developer started the session, she shares the code with other developers who join the session as guests. Most collaborative code editors stream the code in a peer-to-peer fashion to the guest on-demand, e.g. when a guest requests to open a file.
2. Cloud IDEs: similar to Google Docs, where the document lives in the cloud, cloud IDEs host your entire code base on servers in the cloud. It can be accessed by participants either in a web IDE running in the browser, or from a client-side desktop IDE, like VS Code. Examples include GitPod, GitHub Codespaces, or Replit. In contrast to collaborative code editors, cloud IDEs also let you run your code (or tests) in the cloud, e.g. in a Docker container.

In this article, I’ll focus on collaborative code editors. I’ll make heavy use of these terms host and guest throughout this piece, so make sure to keep their meaning in mind. I’m addressing cloud IDEs in this article.

Use cases

Let’s take a look at a few useful scenarios where a collaborative code editor would be useful:

• Coding interview: a time-limited session (up to one hour), where the interviewee joins as guest. The guest contributes most of the code, while the host (the interviewer) follows the guest’s cursor.
• Troubleshooting: a time-limited session where the hosting developer seeks help from, say, a colleague, who joins as guest. Typically, the host will write and debug code, being followed by the guest. The guest may also explore other files to get an understanding of the code base.
• Collaborative coding: a longer session (e.g. several hours), where host and guest(s) both contribute continuously, occasionally following each other. For instance, this is helpful when making substantial, dependent changes to code base, where the asynchronous nature of version control tools (like Git) would negatively impact your efficiency.

Features of collaborative code editors

As outlined in the introduction, collaborative code editors are not exactly equal to collaborative text editors. Similar to Google Docs, you will expect that code editors let several users work on their code. Changes are transferred in real time, and users can see what others are working on, by observing their cursor.

But some code editors have features beyond those offered by Google Docs. Because a code base usually consists of many files, most code editors let guests access and modify different files, independently. A guest can also summon the attention of other guests (or host) to their own cursor, so you don’t have to yell “I’m in this file in that module” over voice chat. Some offer even more advanced features, such as the ability to share a terminal (e.g. UNIX shell or Windows PowerShell), or to use the debugger collaboratively.

Comparison of the top 3 collaborative code editors

Similar to comparison tables such as this one, the following table compares the best 3 editors I could find. While there are more solutions, these are either dead (Floobits, Saros), or their ability to write code productively was extremely limited (Duckly, GitLive): they make it hard to easily navigate the code base, without any “IntelliSense” or auto-complete features.

Each tool is discussed in a separate column. Each row examines a different characteristics. The following list explains what they mean, and what implications they have:

• Host IDE / Guest IDE: software developers are typically used to an Integrated Development Environment (IDE) and don’t like to switch to a different one, because this will limit their productivity. Ideally, there is a plug-in/extension for your favorite IDE that makes it collaborative, because browser-based IDEs often come short in terms of functionality and customizability. As you can see, this is often not the case – only Floobits, CodeTogether and GitDuck offer support for different IDEs. Interestingly, Google Docs has the same problem: its has far fewer features than existing “IDEs” such as MS Word, which is annoying for some users.
• Guest downloads code as files: indicates whether the implementation of the collaborative code editor downloads all files from the host to the guest’s file system. If so, this lets a guest use a different, external IDE they are comfortable with (but changes are only synchronized when saving the file). This also lets a guest keep the code after a coding session ended, which may undesirable from the host’s perspective. Most solutions don’t support this, and instead files are streamed from host to guest on demand.
• No account needed (for host or guest): having to create an account may complicate the adoption of the code editor. On the plus side, this offers the potential for fine-grained access control.
• Share local server port: whether the host can expose a locally opened port to connected guests via a tunnel, which is e.g. useful for web-based development.
• Share terminal: whether the host can share a terminal window with the guests, allowing them read stdout (or give them permission to write to stdin).
• Collaborative debugging: runs the code on the host, showing the debugging information (such as the current line, break points, call stack and variables) to the guests. Guests can control the debugger (e.g. stepping over code).
• Access Host IDE’s smart code assist features: whether guests can navigate and search in the code, based on the source code intelligence features of the host IDE. This includes features such as full text search, jumping from one class to the next (“go to declaration / implementation”), or finding references (“who calls this function?”). This is particularly important for those solutions where files are only streamed from host to guest (see row “Guest downloads code as files”), and the guest would otherwise not know about the existence of other files
• End-to-end encryption: editors without such encryption store the code on some cloud server as clear text. This is unacceptable if you work on proprietary, closed-source code.
• Integrated audio/video conferencing: this is self-explanatory, I hope
• Pricing & license: indicates whether the tool is completely free, or has a free plan with limitations (and other paid plans). OSS stands for Open Source Software.

Impressions

Curious how it looks like? Here are a few impressions of the different code editors:

Conclusion

Collaborative code editors have become increasingly popular, now that COVID-19 has enforced an era of remote work on most companies which create software. These editors come with many advantages over classic screen sharing:

• They allow people to concurrently read and write code independently from each other, which is not possible with screen sharing. If you need to enforce synchronous work, collaborative code editors still have you covered, with features such as a “follow me” button, allowing one participant to force all others to follow their cursor.
• They are much more bandwidth-friendly, which is especially important for workers living in rural areas. Only bits of text are transmitted, and you won’t suffer from “indecipherable text” problems anymore (where details get lost in the video transmission).

But how do you choose the right solution? I suggest to let the use case guide you to make that choice:

• If your use case is troubleshooting or collaborative coding (pair programming):
  • If you work on proprietary, closed source code, consider Microsoft Live share, Code with me, or CodeTogether.
  • If you require the most advanced features, such as collaborative debugging, use Microsoft Live share (if you are a VS Code fan) or Code with me (if Jetbrains IDEs are your favorite). Their downside is that the IDE choice is limited to either Visual Studio [Code] or one of the Jetbrains IDEs.
• For coding interviews, consider CodeTogether. Guests can join without an account, using only the browser. There are also dedicated services for coding interviews, such as CodeInterview and EXLskills.

If you tried the solutions but did not like any of them, consider testing “modern” screen sharing solutions such as CoScreen, POP or Tuple. They allow multiple participants to share one or more individual windows in parallel, in any direction, and show the cursor of the other participants.

Do you know other collaborative code editors I have overlooked? Let me know in the comments!