Collaborative code editors let developers write code together in real time, just like Google Docs. This article compares Microsoft Live Share, Atom TeleType, Floobits, CodeTogether, and CodeInterview. 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.
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. Most collaborative code editors work differently than Google Docs (or other text editors), which are hosted in the cloud, with all users being “equal” contributors. With code editors, however, one developer is the host who has the source code on disk. He starts a session, sharing the code with other developers who join the session as guests. Most collaborative code editors stream the code to the guest on-demand, e.g. when a guest requests to open a file. I’ll make heavy use of these terms host and guest throughout this article, so make sure to keep their meaning in mind.
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 collaboratively debug code.
Comparison of the top 5 collaborative code editors
I have tested and compared a total of over eight editors. Unfortunately, the editors Brackets (with multi-brackets), codeanywhere and TeamHub are outdated. I will not elaborate on them, because they appear to be no longer maintained, which means they will stop working at some point (or are already broken). The remaining five editors are presented in the following table:
|Microsoft Live Share||Atom TeleType||Floobits||CodeTogether||CodeInterview|
|Host IDE||Visual Studio 2017 (or newer) +Live Share Extension,|
VS Code +Live Share Extension
|Atom, IntelliJ, emacs, sublime, neovim||Eclipse, VS Code, IntelliJ||Web browser|
|Guest IDE||See host + web browser||See host + web browser||See host + web browser||Web browser (VS Code-based)||Web browser|
code as files
|Host needs account||Microsoft or GitHub||GitHub||Floobits (create Floobits account using GitHub SSO)||codeanywhere (create via Google, GitHub, etc.)||❌|
|Guest needs account||See host||See host||❌||❌||❌|
|End-to-end encryption||✅||✅ (WebRTC)||❌ (self-hosted enterprise licenses exist)||✅||✅ (WebRTC)|
|Limitations||—||Guests can only see and edit those files that are currently opened on the host||—||—||Very simple editor (e.g. no auto-complete). All code is inside a single file!|
|Pricing & license||Free (not OSS)||Free, OSS||OSS, Free plan (workspaces are public), various plans (private workspaces)||Free during COVID-19 crisis, free limited plan, various paid plans, not OSS||Free, OSS|
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 (and 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. As you can see, this is often not the case (only Floobits and CodeTogether offer support for multiple 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 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.
- Host (or guest) needs an account: 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 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).
- 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.
- 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.
Curious how it looks like? Here are a few impressions of the different code editors:
Since there are so many options, the right tool depends on your needs:
- If your use case is troubleshooting or collaborative coding:
- If you work on open source code (or don’t need end-to-end encryption for other reasons), and require maximum IDE flexibility, use Floobits.
- If you work on proprietary, closed source code, consider Microsoft Live share or CodeTogether.
- If you require the most advanced features, such as collaborative debugging, use Microsoft Live share. Its downside is that the IDE is limited to Visual Studio [Code].
- For coding interviews, consider CodeTogether, Floobits or CodeInterview. Guests can join without an account, using only the browser.
Do you know other tools I’ve missed? Let me know in the comments!