Who wins?

Performance vs. convenience: Desktop or browser-based IDEs?

Tom Radcliffe

SOS distress sign image via Shutterstock

Browser-based IDEs (integrated development environments) are increasing in popularity as their capabilities improve, but they still have a tough road to widespread adoption. Some of the obstacles are only speed bumps, while others are like oceans – there’s just no way around them. Desktop IDEs are comfortably on an island by themselves and it’s up to browser-based IDEs to find a way to bridge the gap.

Benefits of browser-based IDEs

The most obvious benefit that browser-based IDEs offer is accessibility. They allow the user to write code on pretty much any device, as long as it’s connected to the internet. This includes someone else’s laptop, a tablet, or even a mobile phone. If this kind of flexibility is your primary concern, a browser- based IDE might be the right choice.

Getting new hires up to speed becomes easier with a browser-based IDE, as well. The on-boarding process is smoother because your new employees are sharing the same environment as your established employees, meaning that sharing and collaboration aren’t hindered by differences between the environments. Browser-based IDEs necessarily have one common configuration for all developers, which helps everyone on the team avoid the show-stopping line, “well, it works on my machine…”

SEE ALSO: IntelliJ vs. NetBeans vs. Eclipse: Which IDE has the best Angular 2 support?

The preconfigured nature of browser-based IDEs saves you time, but the standardization it enforces might be even more appealing, for some. There’s no desktop customization, so developers have to use what they’re given. Developers usually hate this, but the idea makes some managers start rubbing their hands together in anticipation. Even on the managerial side, though, you might not want to give up control and security for accessibility and standardization.

The case for desktop IDEs

With browser-based IDEs, your code is traveling to the cloud instead of being held locally. This raises some security issues, but developers might be most concerned about privacy. Developers can be a little protective over their code, and having it all out in the open (especially unpolished code) can be a repelling prospect. Nobody wants someone looking over their shoulder all the time. You also have to consider what will happen to your code when the browser-based IDE subscription ends. You’ll lose access to the code you’re storing in the cloud, so you’ll have to migrate it elsewhere before the subscription expires. Desktop IDEs like Komodo allow you to keep your code since the subscription offering is optional and upgrade based.

While standardization is a benefit of browser-based IDEs, customization is one of the draws of desktop IDEs. They can be customized through addons, themes, userscripts, and other alterations that allow you to change the way you work with your IDE. This level of personalization is something most developers prefer, but the main draw for desktop IDEs is performance. Latency is one of the most well-tread arguments against browser-based IDEs. Like traffic jams, not everyone goes crazy when they’re faced with latency slowing them down, but some people lose their minds. Desktop applications are almost always faster than browser-based applications, and this really stands out if your network gets congested, but more on that, later. Desktop IDEs have the edge when it comes to the speed of opening files, editing, and loading the editor, as well.

One of the issues that browser-based IDEs face is that they are (obviously) supposed to be integrated. This means they have to provide build system integrations, error reporting, debugger integrations, and others. And in the case of debugger integrations, if the browser-based IDE does offer this, the UX of
debugging remote builds isn’t exactly stellar. Browser-based IDEs only cover a fraction of the use cases of a true IDE. They’re more like editors and, unless they’re backed by a complete and complex ecosystem on the server, they always will be. Integrations like the ones mentioned above are possible through either third-party online services, or through features implemented in the browser-based IDE, but then you have to rely on third-party online services, which doesn’t exactly scream reliability.

SEE ALSO: Eclipse, NetBeans or IntelliJ: Which is the best Java IDE?

Browser-based IDE reliability also takes a hit when you consider that part of working in a browser is having an internet connection. If you plan to write code on a plane, for example, be ready to pay some hefty in-flight internet prices, or to write it separately and migrate it when you’re connected again. Even if you are connected to the internet, network performance can become a frustrating issue since the performance of browser-based IDEs is contingent on things like server connections and how many people are on your network at one time. And what if the server crashes? If your ISP has issues? If your router has an aneurysm? Desktop IDEs are always prepared to run without an internet connection, so you aren’t dependent on something as touchy as WiFi. Writing code in a browser-based IDE adds complexity to your workflow, and added complexity means that more things can go wrong. Some browser-based IDEs are finding workarounds for some of the downtime issues, but they’re still nowhere near as reliable as offline, desktop IDEs.

The sheer array of tool diversity in desktop IDEs is something else that can’t be matched by browser- based alternatives. Browser-based IDE development tools will improve, but hitting desktop parity is a long way off, if it ever even happens. With desktop IDEs you can use any local tool on your codebase, but this isn’t possible for browser-based IDEs. The browser environment simply imposes too many restrictions on what an online IDE can do, and those limitations are going to be felt by developers.

SEE ALSO: The evolution and future of IDEs

There’s no question that browser-based IDEs are improving, and there’s plenty of praise deserved for the accessibility of the code-everywhere (that has an internet connection) offering. Some new projects are getting closer to desktop editing speeds, and others are finding ways to reduce the reliance on an internet connection by adding some capabilities like editing and saving even when offline, but parity with desktop IDEs is a seeming impossibility. As it stands, the flexibility of writing code on the go is a welcome addition to the field, but is probably best left for hobbyists and others who are relatively new to programming. Serious developers will undoubtedly feel too restricted by the limitations of programming in the cloud.


Tom Radcliffe

Tom Radcliffe has over 20 years experience in software development and management in both academia and industry. He is a professional engineer (PEO and APEGBC) and holds a PhD in physics from Queen’s University at Kingston. Tom brings a passion for quantitative, data-driven processes to ActiveState.

Inline Feedbacks
View all comments