Cloud IDE comparison – the best 9 cloud-based development environments in 2021

A Cloud IDE provides a complete development environment running on a server in the cloud, instead of you running it on your developer workstation. In this article I will discuss general advantages and disadvantages of Cloud IDEs, provide a Cloud IDE comparison of the best 9 IDEs I found, and give recommendations on how to select the one that suits your needs best.

Introduction

As an engineer building software, you typically won’t start from scratch and write Assembly code. Instead, you will reuse existing technologies, selecting one or more programming languages, with additional frameworks and libraries to make your life easier. You also have to choose tools to package and distribute your application, and how to operate it on your servers (e.g. with Docker or Kubernetes).

This plethora of tools cause a problem during development: to actually get a working development environment up and running, a developer needs to download, install and configure a lot of tools (like compilers, IDEs, frameworks, etc.), and run several scripts in the right order. In other words: the on-boarding process is slow, ranging from hours to days. And whenever there is a change in the tooling or its configuration, all developers have to spend time updating their workstation.

In this article, I’ll discuss Cloud IDEs like GitPod and many others, which solve this problem. The basic idea is that all the tooling, and sometimes even the code editor, runs on servers in the cloud, being accessible via the browser. Developers don’t need to install anything locally anymore, because the entire tech stack runs on the server. There is typically a configuration template file that defines how a new workspace instance needs to be configured, with details such as a base Docker image, additional installation of libraries, build configurations and code editor customizations. These files may even be part of the VCS (Version Control System), and a concrete example would be a .gitpod file such as this one.

Advantages and disadvantages of Cloud IDEs

Cloud IDEs have a number of advantages, but also a few problems.

Advantages:

Disadvantages:

Finally, Cloud IDEs make it possible to audit your developers, which may be an advantage or disadvantage, depending on your view point. If a developer uses a local workstation (the “traditional” setup), organizations only see when the developer committed or pushed something to the VCS. But with a Cloud IDE, an organization can track its developers’ activities down to the smallest detail, as potentially every key stroke and mouse click may be recorded. On the one hand, this is creepy and may violate your rights, on the other hand this makes it possible to track how long the development of certain features took.

Cloud IDE comparison – the top 9 candidates

The following table compares the best general-purpose Cloud IDEs I could find in 2021:

To better understand this comparison, you need to understand the meaning of the columns:

• Real-time collaborative editing: whether keystrokes are submitted to other participants in real-time, similar to Google Docs. A solution that does not support this will only transmit changes once a participant explicitly saved a file.
• Shared workspace: whether multiple developers can access the cloud-based workspace, simultaneously. This is a necessary prerequisite for the real-time collaborative editing criterion explained above – but a shared workspace does not automatically imply real-time editing!
• Hosting: SaaS means that the service is fully managed, whereas On-premise indicates that you have to take care of hosting the Cloud IDE, for which you could use a private data center, but also public clouds like AWS.
• Supported IDEs: each provider supports different kinds of IDEs developers use to modify code. All tested providers support web browser-based IDEs, which the providers have sometimes built themselves (see “self-made editor”), or they used existing open source technology, such as Theia, VS Code, or CodeMirror. Some providers also support desktop IDEs (clients that run on your PC or Mac), either via an IDE plug-in, or via a file synchronization mechanism. Even if neither is officially supported, you may still be able to use a desktop IDE, in case the provider offers SSH access: you configure your desktop IDE to access the remote file system via SFTP or SCP (or setting up rsync). However, the level of comfort is decreased, because the developer will have to switch back and forth between coding (in the desktop IDE) and building/testing (in the browser).
• Supported platforms: specifies which operating systems and/or programming languages and frameworks the Cloud IDE is limited to. Some providers will let you do anything that Docker can do, others are restricting you to certain programming languages, for the sake of simplicity / ease of use.
• Sources import options: explains which options you have to get your versioned source code into the Cloud IDE (e.g. GitHub, etc.).
• License & pricing: The license of the Cloud IDE (OSS vs. proprietary) and the different pricing models (including the ability to test or use the service for free).

Conclusion

Cloud IDEs have many advantages, such as being able to quickly spin up new, reproducible workspaces and collaborating with them. You will probably still wonder: should I use them at all, and if so, which one?

My train of thought here is this:

• Take a look at my list of advantages and disadvantages above. Which ones actually apply to your situation? Are any of the disadvantages so severe that using a Cloud IDE stops making sense? For some of these points, trial and error is mandatory (e.g. to determine whether the build speed in the cloud is on par with the build speed on a developer workstation).
  • As for the costs, this is a difficult exercise. Introducing a Cloud IDE would happen for two reasons: economics (saving time&money), and making your organization a nicer work place for your developers (assuming that they appreciate the use of Cloud IDEs). However, estimating how much money you would save (beforehand) is difficult, because it is hard to estimate the time savings that a Cloud IDE will bring. Cloud IDE vendors will promise you the moon, but in the end it is your job to measure and compare the situation (before & after), using metrics. That is: first, find several metrics that measure the costs of the pain points that a Cloud IDE would solve. Second, measure these metrics for a while, using your old approach (without Cloud IDEs). Third, switch to the Cloud IDE and measure again – did you do any better?
• If you are willing to take a shot at Cloud IDEs, consider the columns of the above comparison table to sort out incompatible candidates. For instance:
  • Do you really need workspaces to be shared amongst multiple developers, or are commits to VCS sufficient?
  • Is the web browser-based IDE usable? Are members of your team already familiar with it, and if not, how steep is the learning curve? Is it customizable, e.g. such that each developer can have individually-configured keyboard shortcuts or themes?

In the end, even if you find that the Cloud IDE adoption had too many disadvantages, you can still go back to your previous setup, thanks to the flexible pricing models of Cloud IDEs. If your team finds that the main advantage of Cloud IDEs for them was real-time collaboration, consider my other article about collaborative code editors.

Did I miss any Cloud IDE, or do you know of any additional advantages or disadvantages? Let me know in the comments!