Pros and Cons of Cloud IDE: We gave it a try. Here’s how it went.
Marcin Aman
Team Leader
Michał Wiącek
Software Developer
Published: Aug 29, 2022|14 min read14 minutes read
As developers, we like to rely on IDEs because they increase our productivity. They’re smart tools that can complete the code we write, debug it, and even automate some tasks. In short, writing code with an IDE is much easier than with a plain text editor.
We’ve also all gotten used to the way IDEs work. They take a project, open it, import, and maybe even index it. On simple projects, this process is carried out quite fast. Yet, none of us works on a “Hello, World!” program because printing this phrase does not generate money. In reality, we work on more complex projects, and an IDE can spend anywhere from a couple of minutes to a few hours on those.
The good news is that we may be getting to a point where this flow is no longer necessary and projects open in seconds. Meet Cloud IDEs!
Answering this question requires a super quick introduction to the topic of IDEs. Right now, the most commonly used IDEs are Visual Studio, Visual Studio Code, and JetBrains products (IntelliJ, Pycharm, etc.). At least that’s what developers claim in stack overflow surveys. All those solutions work on a single machine that hosts a code repository and provides all IDE features like code completion as well as code building. This is quite a broad range of responsibilities, especially when we’re talking about a sizable project.
What if we could make a “small” improvement to that scheme? We leave the “frontend” of IDE at a local machine but move all the heavy lifting to a remote computer–one that is more powerful than anything that can be called a “laptop”. That’s how Cloud IDE was born!
To put it simply, Cloud IDE uses two machines: a client and a server. The idea is that the server is spawned on-demand with a special piece of software that exposes an API. The client then connects to this server and writes code or executes some actions remotely. This all sounds like a trivial concept, but implementation is not that straightforward since the primary goal is to provide a smooth experience for developers despite the connection latency. In order to achieve this, communication has to be really fast, and the Client’s and Host’s responsibilities have to be correctly defined.
So, can existing solutions also serve as Cloud IDEs? The answer is, as always, “It depends”. Some IDEs like Visual Studio Code are easier to adapt to the cloud world, whereas others like IntelliJ require more work. Fortunately, this work is already mostly done, and we can try out remote Visual Studio Code, Jetbrains Client or even a new, cloud-native, IDE from Jetbrains: Fleet.
What if we tell you that you can contribute to the biggest repositories on GitHub and have other projects open at the same time? With no chance of running out of resources on your local machine? Even if your computer has hardware that is much closer to a potato than you would like it to be. Really!
The biggest advantage of Cloud IDEs is that they have a very thin client that can work on basically everything. Some of them, like Fleet or JetBrains Client, have a desktop app, but it can get even more simple than that. Visual Studio Code can run in a browser, which is useful if you wanted to do some development on the go using an old Chromebook that you bought but never had any real use case aside from browsing Twitter. All of the heavy-lifting tasks like compilation or code analysis are done on a remote machine. The client only gets its output. The added benefit is that you no longer need to deal with the “it works on my machine” problem because all the machines have fresh, standardized environments that you can share and collaborate on with your team.
Developing a web application
One of the most popular workflows that developers have is maintaining and improving web applications. For better and for worse they are probably what most of us do for a living. Let’s see if we can make a dull experience of CRUD-ing any better.
First of all, let’s assume that your application consists of a frontend, backend, and maybe some other services like a database. All of the code is contained within a single git repository that just has a couple of modules. Here, Cloud IDE excels because you can set up frontend and backend within a single IDE. Running a web application in a remote IDE is the same as running it locally except you do not need to care about having the right setup, dependencies, or OS. If it works for your colleague, it will work for you.
At first, it may not be obvious how one can use an existing development stack, including Docker. After all, it is 2022, and most of us do not need to meticulously set up the appropriate PostgreSQL version. It is fairly common to have a Docker Compose with a database or some authentication provider. While the exact implementation details will vary depending on the Cloud IDE provider, the basic principle will be the same: you have full docker access, and you can do whatever you would like to. Same as on your machine.
Moreover, most often you would like to see the results of your work in a web browser or using some “specialized” tools like curl or postman. This can be quite tricky because the question is “how can I access a port that is on some random host?”. Fortunately, with a Cloud IDE, this issue is solved, and with a few clicks, you can expose a port to your local computer! It is way easier than hand-crafting such a solution using something like ngrok.
So it turns out I can develop a web application inside a Cloud IDE, but should I?
We asked ourselves the same question before giving it a shot. Our test was simple: let’s use it for a couple of weeks as our primary IDE and see how it goes.
At first, it was quite awkward because none of us knew what to expect. But after a few hours, it felt just like a local IDE that doesn’t slow down a laptop during compilation. I must admit that it was a bit strange not to hear the sounds of a laptop cooling itself down during the compilation of a sizable codebase. You have a feeling that the compilation is not working because it is not doing anything locally. After a week or two of using it, I got so used to it that I felt the opposite: why do I hear my colleague’s laptop turning into a spaceship whenever he does anything? The lightness that Cloud IDE provides is something else, especially when you work on a project that requires a lot of resources.
Aside from that, I didn’t have any issues related to tools not working with Cloud IDE. Most of the tools work, you just need to expose the correct port. You can even connect to a database from IntelliJ or check out the frontend in the web browser (did I mention that live reloading of the frontend also works as expected?).
Contributing to a library with Cloud IDE
Although it is 2022, some of us still create libraries so we can use them on our local machines. Creating a library has a bit of a different set of challenges than web development. Sometimes you have to verify how a library works locally or build multiple ones, each for different operating systems.
We have tried to contribute to ide-probe using gitpod.io, so I will focus on the first one.
Ide-probe (as mentioned in the Readme file) is a framework for testing plugins for IntelliJ-based IDEs and consists of the plugin itself too. By enabling xvfb and having the Docker daemon available, we can run all available tests one way or another. Unfortunately, there is no way to run tests using a native display. This part has to be done locally. Luckily, Gitpod has Tailscale integration, which is a lightweight VPN that allows you to automatically and securely connect to your workspace and download artifacts (library plugin or anything whatever you want) either from or to your local machine. This approach could be also considered for mobile application development.
We have integrated it with our repository. So everyone can try it with a single click (if it is not a problem for you, to add Gitpod integration to your GitHub account).
What is even better, by installing the Browser extension, you can try it with any repository. Contributing to open source becomes fairly simple with this approach.
Snapshots aka prebuilds to the rescue
One of the key challenges of running a fresh machine with an IDE is that you will always have to go through the dull experience of waiting for the building and, in some cases, indexing to finish. It’s nice to have an undeserved coffee in the meantime, but sometimes it is just annoying to wait.
The problem of long wait times was solved by snapshots (called pre-builds for gitpod.io). This mechanism runs on some sort of CI and is responsible for building a project and packing all the necessary stuff into a container that users can download. You do not have to follow complicated guides that are in many cases obsolete or not maintained correctly. All required local caches are populated, required plugins installed, and services configured. Fabulous, just like development should be in the 21st century! No boilerplate, just code.
“How is it done?” you may ask. The answer is by using the simple, loved by everyone, YAML configuration file with an additional DockerFile:
1FROM gitpod/workspace-java-11:latest
2
3USER root
4RUN echo "deb https://repo.scala-sbt.org/scalasbt/debian /" | tee -a /etc/apt/sources.list.d/sbt.list \
A Cloud IDE is not for everyone. First of all, to use it you need to have the Ultimate version of JetBrains products. Another disadvantage of using a Cloud IDE is that you need to pay for the machine. Is it a lot? Well, it is hard to tell right now because everyone is trying to get customers on board by offering free/cheap tiers. You can check up-to-date pricing on Gitpod’s or Space’s websites. However, right now you can use 50hrs/month on Gitpod for free! Keep in mind that you can also self-host it if you happen to have your own infrastructure.
When evaluating the above-mentioned solutions we knew that most of them were in beta. This is especially true for the JetBrains stack. There were lots of UI issues, but none of them blocked us from using it effectively. In fairness, we experienced a crash maybe once or twice, but that’s acceptable for such an early version. What surprised us about Cloud IDEs is that each action, like opening a window or writing a piece of code, was done quite smoothly and (with a decent internet connection) we were barely able to spot a difference between it and our local IDEs. That’s great news going forward, because it is way easier to fix some bugs than to optimize communication with the server.
What also was positively surprising is that using hosted solutions was… simple. You just click on what you want, wait for a second, and it is ready. On the other hand, Gitpod’s prebuild didn’t speed up the process as expected, because it failed to index some libraries and Gradle caches required by IntelliJ. We assume that this is just a bug, but it is worth re-checking while working on your project.
So, is a Cloud IDE a holy grail that will solve all of a developer’s problems? Well, it definitely won’t motivate you to write better code. But if you feel like your IDE is slow because of the project size, or maybe you work on multiple projects and setup takes a long time, then it is a solution you should at least try. Do we believe that Cloud IDEs are the future? Yes, for better and for worse.
There are a few places that you can try using a Cloud IDE to see if it’s the tool for you. At the time of writing this blog post, you can get 50 free hours a month from gitpod.io. This is a great option if you would like to see how the experience is and don’t want to spend money to do so. They have even created a Chrome plugin that lets you open projects from GitHub with a single click. Nice!
There are also some paid options, so if you don’t mind paying a few bucks, then you can try out Space or Coder.
If you’re interested in improving developer efficiency, you may also like these case studies:
