With the resurgence of Cloud IDEs as part of the development workflow, and unusually, as part of the Cloud Native movement as well, most developers ask: "Do I really need to use a Cloud IDE?"

I, myself, have experienced both experiences, as some developers has did as well. I came from an era where Visual Studio Code was still in it's infancy, and we had to use something like Komodo IDE if we wanted top notch IntelliSense and code linting.

But nowadays, with the emergence of GitHub Codespaces, Gitpod, and Eclipse Che, it's almost that we have too many options for tooling nowadays - and all of them are much more richer and extensible than the previous generation of editors.

However, with so much options, when does the choice between a browser-based IDE and an IDE you can execute within your start menu or launchpad matter?

What made Cloud IDEs successful?

The idea behind Cloud IDEs are the concept of "portable workspaces" - that is, for every machine you own, you have the same set of tools, you just need to open it from a workstation with only a browser and that was it. You just need to open a link from another machine and you're back to where you've started.

What also garnered the attention of the many was Cloud IDEs allows customizable, reproducible stacks that you can write once and it works for all machines, no more case of "it works on my machine" if they all rely on the same configuration. It also allows the code to stay only on the servers they belong to as well, increasing security for code developed in air-gapped environments.

But it can't replace localhost, and never will.

Cloud IDEs may have won over the masses for their flexibility and reproducibility, however, Cloud IDEs can never replace traditional localhost development. Why? Because of these primary reasons:

• Most of the development going on in Cloud IDEs are focused on online distributed systems. GUI programming is sparse because of their container-focused nature.

• Cloud IDEs usually do not support HPC (High Performance Computing) programming like GPU compute unless you rely on a large provider like Azure or AWS which allows such. But for most cases, generally available Cloud IDEs only expects you do regular programs like CLI programs or CPU-bound ones.

• The cloud has latency. No matter how much you try, the latency of Remote Procedure Call Protocols is always higher than wired ones. While we had services like game streaming invest of trying to lower this latency, the cloud itself is in no way a good development environment if you want to program for least-latency.

Most evangelists also preach that in a few years we can switch everything to the cloud. I can bet you a thousand dollars right now, that it's technically infeasible to have everything moved to the cloud, even if we look forward to 5 or 10 years in the future.

But they do have a place and purpose

Cloud IDEs and Desktop IDEs are tools to help you write code more efficiently. We shouldn't argue which is better since every option has its own Achilles' heel. Cloud IDEs are good for programs that are usually on command line or requires a web interface, and desktop IDEs are good for what the Cloud IDEs can do as well but they can do more like programming for native GUI.

It's either preference or the security requirements that decide which tools you should use. But for personal preference, you should learn to experiment and decide which works best for you.

Conclusion

While Cloud IDEs has recieved major attention due to the cloud trend, it certainly isn't a one-size-fits-all solution. It's always the requirements of the application will decide if you should use it, or your personal preference.