Cloud IDE vs local IDE: Understanding the differences

Erik Bledsoe

 on June 30th, 2021

An integrated development environment (IDE) is a suite of applications used by developers for writing and building applications. Typically, an IDE provides a graphical user interface (GUI) and includes:

• Source code editor: all applications begin with a line of code, and the editor is where the developer writes that code. In its most basic form, this is a text editor, but most editors include features such as syntax highlighting and autocompletion.
• Build automation tools: these tools take the written code and, through a series of automated tasks, turn it into code that can be executed and run on a machine. These tasks may encompass several tasks including documentation, testing, compilation, and distribution of the binary software code.
• Debugger: a debugger is a tool for identifying errors in the source code. In many cases, this can happen in real-time as the developer is typing.

The best IDEs are tightly integrated, allowing developers to work quickly without requiring them to switch between different applications to complete tasks.

Traditionally, developers have run their IDEs on their local machines. In the last few years there has been a growing interest in moving development workspaces and IDEs to the cloud. We’ve written before about some of the advantages of cloud-based development as well as some of the roadblocks that have prevented more developers from moving to the cloud.

In this post, we will lay out some of the fundamental differences between using a local IDE versus a cloud-based IDE and explore some scenarios where you might prefer one over the other.

What is a local IDE?

Installing and running your preferred IDE locally is the most common way of working for developers. The current reigning champion of local IDEs is Microsoft Visual Studio. Exact market share numbers are difficult to determine, especially because some surveys lump together Visual Studio and VS Code while others separate them, but estimates suggest that Microsoft controls anywhere from 28% to over 40% of the market. Another common choice is Eclipse, which is primarily used for Java development but which now supports many other languages as well.

To get started using a local IDE, a developer needs to download and install the IDE, which may be as simple as launching a binary file or it may involve many complicated steps and terminal commands. Once the IDE itself is installed, the developer may still need to download and install various libraries and project dependencies. This must be done carefully and with knowledge of the environment where the finished project will run since code that works when tested on the local environment may not perform correctly (or at all) in production environments if the required libraries are mismatched, a situation known as configuration drift.

Benefits of using a local IDE

Customization

Many IDEs allow users to install extensions or plugins that add features or tools that support their development workflow. Microsoft’s marketplace currently has almost 11,000 extensions for Visual Studio and over 27,000 for VS Code, allowing users to add support for Python or to deck out their workspace with a Game of Thrones-inspired theme. If you need VS Code to do something that it doesn’t do out of the box, you can likely find an extension that will make it work — or you can build your own custom extension.

Lots of free and open source options

There are a ton of local IDE options out there. VS Code certainly owes some of its popularity to being free. Even most of the paid IDEs have a free version that may lack certain functionality (e.g. Eclipse).

No internet connection required

Once you have your development environment set up the way you want it, you can unplug and get to work. By their very nature, using a local IDE means that once you have everything set up, you are self-contained with everything you need. Knock out a few hundred lines of code on your next flight without shelling out for the crappy airplane wifi? No problem.

Pain points of using a local IDE

Installing and configuring your environment

Setting up an environment can take a lot of time. Most developers report taking at least 2-4 hours and sometimes much longer. For developers working in highly regulated industries, it can take weeks. Depending upon the number and nature of projects you work on, you may need to set up a new environment multiple times per year.

This task can be especially daunting for inexperienced developers, and can even be a security risk. I confess — in my past I have copied and pasted commands that I found by Googling problems without fully understanding what the commands would do (other than hopefully fix the problem I was having).

If you are developing software as a hobby, then it doesn’t really matter how long it takes you to set up your environment, and doing so can be a fun and enlightening experience (if sometimes frustrating). But if you are being paid to write code, then your employer would probably rather you spend your time actually writing code, and they certainly don’t want you putting the corporate network at risk by typing in commands that you don’t fully understand.

Configuration drift

Environments are not static. There are always security patches that need to be installed, updated libraries that should be evaluated, etc. This is how configuration drift begins. Someone makes a change to the production environment and doesn’t effectively communicate and then the next deployment fails even though “it worked on my machine!” Trying to keep large teams in sync is a nightmare when every developer is responsible for configuring and updating their own local development environment.

Compute intensity

Code editors, even the ones that provide autocomplete and syntax highlighting, are essentially text editors and require very little compute power to run. When it comes to assembly and compilation, though, you are going to want to have the beefiest (and hence usually the costliest) machine you can afford. Even mundane tasks like checking email and responding to Slack can become impossible when your CPU is running at 100% because your machine is working hard to compile your code.

What is a cloud IDE?

When people think about cloud IDEs they often envision an environment running on a server somewhere and accessed entirely through a browser window. This is indeed the typical model. However, some offerings also allow you to run an editor locally while the other components of the IDE run in the cloud. The distinction is important, but for my purposes here I will consider both to be cloud IDEs. What defines a cloud IDE is where the bulk of the development environment resides, especially the compute-intensive tools for debugging, building, and compiling.

Benefits and pain points of using a cloud IDE

To understand the benefits and pain points of using a cloud IDE you can basically take the points above about local IDEs and flip-flop them.

Pros

• Imagine having a fully configured developer workspace available in minutes that includes your favorite IDE and all of the environmental configurations that match your production environment. Cloud IDEs make reproducible environments not only possible but easy. At Coder, we had a new hire commit hundreds of lines of new code on their first day because they could onboard immediately.

• With reproducible environments, configuration drift becomes much less of an issue. When development environments are built from an image, a change to that image can be pushed out to the entire team. Everyone stays in sync.

• With cloud IDEs the cloud does the heavy lifting of assembly and compilation which means that the developer doesn’t require a maxed-out personal workstation. When one of Coder’s engineers had to send his laptop in for repair he used an iPad to continue working for two weeks.

• You can continue to use the same IDEs you prefer locally, except in the cloud. This is not true in all cases — some companies have built their cloud IDE offering from scratch. Others, like Coder and Gitpod, use VS Code as their default IDE experience, letting developers continue using the tools they already love, just powered by the cloud.

Cons

• With cloud IDEs, you may have to give up some ability to customize your environment — although perhaps not as much as you might expect.

• There are fewer open source and free solutions. If the IDE is gonna live in the cloud someone needs to pay the cloud costs. There are some open source options that you can install on your own cloud-based server, including our own code-server project, but you’ll need to foot the bill for the cloud services. There are also some free cloud IDEs, but they usually are limited to working on other paid services such as Cloud 9 on AWS or CodeReady Workspaces on RedHat’s OpenShift platform.

• Some cloud “IDEs” are really little more than glorified text editors and lack the features that developers have come to expect from their IDEs.

• Today it is necessary that you have an internet connection to use your cloud IDE. But conversely, if you have an internet connection you’ll be able to access your environment wherever you are. Want to spend a week working from a Caribbean resort? No problem. At a party and you get a PagerDuty alert? Hop onto your friend’s computer and access your environment. Of course, you would never go to a party if you were on call, so this example probably doesn’t apply.

Use cases: Local vs cloud IDE

So which is right for you? It depends on your situation and what challenges you face, but here are a few suggestions.

Remote teams

The COVID-19 pandemic greatly accelerated the trend toward remote work and work from home. With a widely dispersed workforce, ensuring that everyone is using the same version of required libraries becomes even more difficult. In some cases, engineers may be using their own personal devices rather than company-issued equipment. In instances like this, having a centralized cloud IDE makes a lot of sense — engineers can connect to their environments from anywhere using any device, and the environments are easily reproducible.

Use case best served by: Cloud IDE

Limited broadband

Some of us are used to having enterprise-level broadband at the office and gigabit connections at home. But many others must deal with spotty connectivity and limited bandwidth, especially when working from home. And even in the United States, there are still many areas where broadband is simply not available. In such cases, developers may be more productive by having their workspace self-contained and not dependent upon their internet service provider.

Use case best served by: Local IDE

Gig workforce

Contingent workers make up a significant portion of the software development workforce. If your company employs a lot of contract workers for your software development needs then using a cloud IDE can significantly reduce the onboarding time as well as enable a bring your own device policy and save your company money.

Use case best served by: Cloud IDE

Hardware limitations

If your personal devices are underpowered or otherwise limited running an IDE locally may not even be possible. This is where having a cloud-based IDE really excels. A Chromebook is fine for typing out your code and commands, but having your IDE actually running on a server that can burst up and provide you with whatever power you need when you need it can’t be beaten.

Use case best served by: Cloud IDE

Customized editor preferences

Developers can be picky about their workspaces and workflows. Most local IDEs can’t be beaten for their ability to be customized. Some cloud IDEs offer little or no ability to customize your workspace, others, however, allow a great deal of customization. In this case, it really depends on which specific IDE you are using.

Use case best served by: either, depending on which product you are using

Conclusion

Both local and cloud IDEs have distinctive advantages and disadvantages. What works best for you depends upon your situation and needs.

If you would like to explore the potential for cloud-based IDEs in your workflow, try out our open-source project, code-server, to host VS Code on a server and access it anywhere remotely from the browser. We are also currently offering a two-month free trial of Coder, our enterprise product that builds upon code-server and adds features designed for teams including support for additional 10+ IDEs and advanced security features.