Web-based vs. desktop-based Tools

It is clear that there is an ongoing excitement surrounding web-based IDEs and tools, e.g. Eclipse Che, Eclipse Theia, Visual Studio Code, Atom or Eclipse Orion. If you attended recent presentations or read current announcements, you may get the feeling that desktop IDEs have already been deprecated. But is this really true? If you ask developers for the tools they use in their daily work, you will rarely find someone already using web-based development tools in production.

At EclipseSource we develop IDE-based solutions, development tools, tools for engineers and modeling tools on a daily basis in various customer projects. We are dealing with this particular design decision regularly:

Do we go for a desktop tool, a web-based, or cloud-based solution?

Therefore, we want to share our experience on this topic. This is the first of three articles. It describes the most important drivers behind any design decision: the requirements. In the second article, we will describe challenges, technical patterns, solutions, and frameworks on how to match the requirements and how to remain as flexible as possible. In the third article, we will provide an example scenario to substantiate those best practises.

So first things first: As for so many design decisions, the most important thing is to know the requirements. Software Engineers love to talk about implementation and we also like to use new, fancy, or just our favorite technology. But in the end, we need to solve a given problem as efficiently as possible. Therefore, we should think about the problem definition first, even if that leads to a design decision that doesn’t bet on “what’s trendy right now"?

For the impatient reader, here is the possibly unsatisfying conclusion: Whether to go for a desktop or a web-based solution is a complex decision. If you want to make an optimal choice, you will need to consider your custom requirements in several dimensions. For some projects, it will be a rather simple and straightforward choice, e.g. if you are required to integrate with a given existing tool chain. However, for most projects you will need to consider the overall picture and even try to predict the future as accurately as possible.

In our experience, it is worth the effort. In the end, you will hopefully develop a good strategy. This strategy does not have to be limited to strictly choosing one option. It is also a perfectly valid strategy to choose one primary option, but also to decide on being compatible with another option. This allows for a future migration path forward. Further, it is possible to mix both worlds on a per use case basis. We will detail these particular strategies in a follow-up post.

So let’s look at the most common non-functional requirements, which play a role in the design choice between desktop and web. To be more precise, the following areas are typically treated as advantages of a web-based solution.

• Installability: (also referred to as deployment or “set-up effort”): How easy and fast can you set-up the required tooling and the runtime for executing a system. Usually this is mainly referring to the developer tooling and its runtime(s) since it needs to be repeated for every developer. For simplicity, let us assume this also includes the effort to keep the system up-to-date.
• Portability: How difficult is it to port a tool to another platform/hardware. In the case of IDEs this requirement is also sometimes referred to as “accessibility”. The typical use case is to access all development resources from any platform, e.g. also on your mobile device.
• Performance and responsiveness: How responsive is the tool or how responsive does it feel. How long do crucial operations take to run, e.g. a full rebuild.
• Usability: Let us use this wonderful definition from Wikipedia: “In software engineering, usability is the degree to which a software can be used by specified consumers to achieve quantified objectives with effectiveness, efficiency, and satisfaction in a quantified context of use”
• Cost: The cost it takes to implement an IDE, tooling, extension or the necessary development runtime. For most projects it is probably one of the most important criteria to consider

Besides those non-functional requirements, tools also need to fulfill functional requirements. As those are specific to a certain tool, we will only consider the cost requirement since typical projects are aimed at fulfilling their functional requirements at the lowest possible cost.

As a first requirement, we will look at installability, because it is the most obvious distinction between a desktop-based and a cloud-based solution. For this requirement, we will also introduce some example scenarios and dimensions, that recur for other requirements later on, so the next section is the most comprehensive.

Installability (a.k.a. Deployment, “set-up effort” and updatability)

Installability is probably the most prominent advantage that is advertised for web-based solutions. The vision is that you can simply log into a system via your Browser and you can directly start to code without installing anything, neither the IDE or tools, nor any runtime environment. Further, you do not need to install any updates anymore, as they are applied in a central way.

So let us look at this obvious advantage more in detail. The first interesting dimension of this is how much time you can save with improving the installability. This is connected to the number of developers that you have on-board to use the tooling and the number of people who are occasionally using those tools. Further, it plays a role on how long a developer would use the tool after installation, the shorter the usage the more significant the set-up time would be.

Let’s look at three example scenarios.

First let’s consider a tutorial/training scenario, where participants should participate in completing exercises. A tutorial/training takes usually a couple of hours or days, so the set-up time is a crucial part here. Further, trainings/tutorials are typically conducted for a bigger number of developers. Anybody who ever had to deal with preparing a setup guide for a tutorial would agree that a browser-based solution would immediately pay off here. Even the simplest and best prepared desktop-based setup will take some time to install. So this scenario is a win for a web-based solution if, and only if, you can rely on a robust high-speed internet connection. Consequently, you can observe that a lot of online tutorials already embed web-based code editors and tooling.

The second scenario is an open source project. Many OS project have a mix of different developer roles. Some developers (committers) are regularly contributing to a project. The second group of contributors typically uses a technology (“adopters”), but want to eventually contribute small enhancements and fixes. While for the regular committers, set-up is not that important compared to their time working on the project, occasional contributors are obviously often discouraged from contributing to a project by a complex set-up. Therefore, in this scenario, there is a mismatch between the requirements of two user roles that you need to balance. So is it worth to switch existing committers to a cloud-based solution to ease the life for contributors?

Ed Merks has described this issue very well in his blog post in 2014. His conclusion was the creation of a tool called Oomph, which automates the set-up of a desktop IDE for projects. For the source code, Oomph even goes partly a little further than most cloud-based solutions, as it even allows you to automatically check-out the sources. Please see here for a tutorial regarding Oomph. While Oomph greatly improves the set-up process, it does not solve the issue completely. It will still take some time to materialize all project resources (i.e. download time). So for a very small contribution, it might still be too much of a burden. Further, it does not fully automate the creation of an appropriate runtime. If a project requires a lot of external tools (e.g. databases, applications servers, etc.), those have to be installed separately. In turn, it does not touch the regular committer user, as they just continue using their existing and well-proven solutions. In scenarios with such different roles, it is always a good idea to let all developers use the same set-up and tooling. Otherwise, there might be slight differences in their output and further, the committers will usually only maintain their solution well.

The third scenario is not differentiated by the type of project, but by the use case: code review. In a scenario where a developer works on implementation within a project every day, she might not care about installability so much, at least other requirements might be more important. In turn, if you only review a code change and you do not implement something regularly, installing/updating all the required tooling plays a significant role. As a consequence, most reviews are already probably done in web interfaces (e.g. Gerrit or Pull Requests). Also the use case is focussed on reading and understanding code, rather than on changing or creating new code. Therefore, other requirements are not so important for a code review compared to a good installability.

Like the three scenarios described here, you can categorize any arbitrary project and the according use cases based on the importance of a good installability. The result of this will be very specific to a custom project set-up. Those considerations are naturally already reflected in today’s toolchains, where parts of the tool chain more focussed on reading or browsing code are often web-based.

There are some more considerations to make, which are related to installability. One is the updatability. While of course an update to the tooling is hopefully not the same as installing it from scratch, most considerations we had for the installability should be applied for the update case as well. This especially includes, how often updates to the tool are applied.

Another obvious dimension is the complexity of the project set-up. The more difficult it is, the bigger the advantage of simplifying it via a cloud solution. For this, we need to differentiate of course between the IDE tooling itself and the necessary runtime environment. The environment is often much more complicated, e.g. if you need to set-up several services, databases and so on. If only the runtime set-up is very complicated, a cloud-based IDE might not be the only valuable solution. There are several ways to ease those setups, even without using a cloud- based IDE, e.g. with docker containers or workspace servers like Eclipse Che.

Installability is one of the major advantages of a web-based solution. However, it will only provide a significant advantage, if the use case fits. Therefore, it is worth it to spend some time on defining the core users and use cases of your system and define the importance of installability for them. In a nutshell, installability pays off most in environments, where a lot of people need to and can be on-boarded very fast, and if they do not work continuously on a project. Unfortunately, when onboarding developers it is usually much more time consuming to transfer the required knowledge than to setup the IDE.

Portability

Portability is the second very obvious advantage of a cloud and browser-based solution over a desktop-based tool. The ultimate goal is that you can access the tooling and runtime with any device which has a browser. As a consequence, you can ideally fulfil your development use case at any location, even from a mobile device. In some discussions, this is currently referred to as “accessibility”.  While this strictly speaking means something different, we consider Portability as the ability to access the tool from anywhere on any device.

A lot of the considerations we have described for installability can be shared when thinking about the advantage of Portability. Different project roles and different tooling use cases would benefit on a different level. Doing a code review or browsing a diagram on a tablet makes more sense than writing a lot of code. So, again, the detailed roles and use cases will need to be evaluated. We will not repeat that in detail, but focus on new dimensions, which are specific for portability.

One additional scenario connected to portability is the ability to share a certain runtime set-up or project state. That means developers always have exactly the same environment. This obviously simplifies life as the typical phrase “I cannot reproduce this on my machine” would no longer occur. However, this only fully applies to the tooling. For the runtime, it plays a role if the runtime platform for a system is unified, too. If the system under development runs natively on different operating systems again, you still need to test different runtime environments. As a consequence, cloud-based tooling currently seems to get adapted in the area of cloud-based development, first.

And like mentioned for installability, there are other ways to achieve a uniform setup, although not as unified as a cloud solution.

A disadvantage of a pure cloud-based solution is that they often rely on constant internet connection. While this issue becomes less and less relevant, at least it must be considered. Some cloud-solutions already provide a good work-around, e.g. the offline mode of Google Mail.

A final word about the dream to be able to contribute to a project from anywhere on any device: While this sounds appealing for certain use cases, do we really want to be called by a client and subsequently feel obligated to fix a bug on our smart phone while we are sitting in a ski lift?

Performance

Performance is a very interesting requirement to consider. In contrast to installability and portability, there is no clear winner between desktop-based and cloud-based tooling. You will find valid arguments for both to be “more performant”, e.g. this article by Tom Radcliffe claims that desktop IDEs are the clear winner.

The major reason for this tie is again that we have to consider the specific use case when talking about performance. While writing and browsing code, we want fast navigation, key bindings and coding features such as auto-completion. While web IDEs have caught up a lot in recent years, you can still claim that a desktop tool is typically more performant for those “local” use cases (as also claimed by Tom Radcliffe in the article referenced above).

Things change, when looking at other use cases, e.g. compiling. A powerful cloud-instance can certainly compile a project faster than a typical laptop. Further, it is comparably cheaper and more scalable to gain more resources in a central way. However, when going for a cloud-based solution, scalability must be taken into account. Any advantage is obsolete, if developers have to wait 15 minutes for getting something compiled, because other build jobs are running on the central instance.

So for performance, it is important to consider which development use cases are crucial and will benefit performance-wise from either solution. A follow-up decision of a cloud-based solution would be to strip down the hardware for participating developers to save costs (Chromebook scenario). While this sounds like a rational thing to do, not everybody will like the idea of giving away his or her powerful device.

Usability

Usability also doesn’t have a clear winner in the comparison between desktop-based to web-based IDEs. While advocates of both platforms would claim a clear advantage, this is really a matter of personal taste. Web technologies have become incredibly powerful when it comes to styling, look, and feel. Therefore, you can achieve almost any visualization you would like.

Further, there is much more innovation going on in the web area in comparison to, e.g. SWT.

On the desktop, depending on the UI Toolkit you use, there might be more restrictions. JavaFX and Swing are powerful when it comes to styling, but Swing is kind of deprecated. SWT has limitations when it comes to styling. However, it probably provides most existing framework support when it comes to tooling (see also “cost vs. features”).

Besides styling, native desktop applications have still some advantages in usability, e.g. by supporting native features such as application menus, tray icons, key bindings and such. Although, it is expectable that these advantages will shrink over time as  browsers keep on evolving very fast. In any case, usability is not equal to the ability of supporting a dark theme as some browser advocats may try to make us believe.

It is worth mentioning that there are platforms combining advantages of both worlds. Platforms such as Visual Studio Code, Atom or Eclipse Theia embed web technologies (HTML and Typescript) into a desktop application (using Electron).

Cost vs. Features

At the end of the day, for many projects a very important constraint is cost, meaning the required effort to satisfy your list of functional requirements. A comparison of the required effort on either platform is driven by several parameters.

First, the effort would be influenced by the general efficiency of a certain platform. It would go beyond the scope of this article to compare, for example, the efficiency of Java development with TypeScript or JavaScript development, so let us assume the general development efficiency to be equal for now.

Second, cloud-based solutions usually add some complexity to the architecture due to the required encapsulation of client and server. Of course, you want to have encapsulation of components in a desktop-based tool, too. However, you typically do not have to deal with the fact that components are deployed in a distributed environment.

Third, a very central aspect for implementing tooling is the availability of existing frameworks, tools and platforms to reuse. Ecosystems like Eclipse have grown over 17 years now and already provide a tool, framework or plugin for almost everything. Many requirements can be covered with very little effort, just by extending existing tools or by using the right framework.

While there are frameworks for cloud-tools, too (such as Orion, Eclipse Che or Theia), they are arguably not as powerful as Eclipse/IntelliJ/NetBeans, yet. This might of course change over time.

One mentionable trend is to reuse existing “desktop” components in web-tooling. As an example, Eclipse JDT provides an API to be used using the language server protocol (LSP). This allows you to reuse features such as auto-completion and syntax highlighting from another UI, typically a web-based IDE. While LSP does not yet cover the full feature set of the Eclipse desktop IDE, it is a great way of reusing existing efforts.

Finally, powerful frameworks usually also carry the burden of complexity. The advantage of reusing existing stuff typically (or hopefully) justifies the effort of learning to use a framework. In turn, if you just use a tiny bit of a platform, you might be better off in using something slimmer, which covers your use cases just as well. As an example, if you need a plain code editor without any context, e.g. for a tutorial use case, a platform such as Eclipse might be overkill.

So it is useful to evaluate the desired feature set and how well it is supported by existing frameworks on the respective technology stack (web vs. desktop). It is also worth it to investigate whether existing features on one stack can be adapted to be reused on the other (e.g. using LSP). This applies in both directions. Not only can you call existing frameworks in the background from a cloud-based solution, it is also possible to embed web-based UI components into desktop applications (see also conclusion).

Finally, what makes the dimension of cost vs. features especially difficult is that you typically cannot know exactly what kind of features you need to provide with a tool in the mid-term future.

And more…

There are obviously many other parameters to consider when comparing the costs of cloud vs. desktop-based tools. This article would go beyond scope if we were to spend a section on all of these, but let us at least mention some more important topics.

One meta criterion in the decision for a platform, framework, or technology stack, is the long term availability as well as how actively it is maintained. Again, there is no clear winner, when comparing desktop and web stacks. While you can argue that there is more development going on in the web area, it is in turn extremely volatile. Platforms such as Eclipse have been successfully maintained for 17 years now. There are existing workflows for long-term support (LTS) and suppliers like us providing this as a service. Plus, the platform is very stable in terms of APIs.

In turn, web frameworks provide major version updates with improvements almost every year. While this brings in innovation, it also often requires refactoring of an adopting project. As an example, there is currently a lot of variety emerging when it comes to web-based IDEs (e.g. Visual Studio Code, Theia, Eclipse Che, Orion, etc.). We will cover strategies to deal with this risk in a follow-up article.

Another meta criterion is the availability of skilled resources. At the moment, you can probably find more Angular developers on the market than SWT experts. However, this may change very quickly - once Angular is not “hip” anymore.

Another frequently discussed topic when it comes to cloud-based solutions is of course the security as well as tracing aspect. While it is certainly worth considering, it is probably not the key decision factor for most professional environments, but rather requires special attention.

Conclusion

In this article, we have tried to cover the most important considerations when deciding between a cloud or web-based solution and a desktop tool. There are for sure many more things to consider.

However, what all dimensions have in common is that it is most important to think about the users, their use cases and the frequency of those. Based on these criteria, you can evaluate the benefits of supporting them in the web or on the desktop. This is especially true, if you already have an existing tool and are considering a migration. In this case, there must be clear advantages justifying the cost.

While this is already complex, it is even worth it to make this decision on a per use case basis. This is already happening naturally in our tool landscape, e.g. code reviews are very often conducted using web-interfaces. Identifying the use cases in your tool, which would benefit most from being available online, reduces the effort and risk to migrate everything at once. So it is often a good idea to pick the low hanging fruits first.

Ultimately, it will almost never be possible to make a perfect decision. This is especially true, as important criteria, use cases, and technologies change over time and no one can perfectly predict the future. Therefore, the most important thing is to keep some flexibility. That means, even if you decide for a desktop solution, or vice versa, it should be as easy as possible to switch to the other option later on.

Even mixtures of both technology stacks on a per use case basis often make sense. While this sounds ambiguous, there are some simple patterns to follow to make this true. We will highlight those strategies in a follow-up article. This strategy also allows an iterative migration, which is often the only viable way tackle the complexity and efforts of migrating existing tool projects. Some Frameworks even proactively support this strategy by supplying implementations based on web- and desktop technology at the same time, e.g. EMF Forms and JSON Forms.

Let us close this article with a general, non-statistical overview of what most projects currently do. This is of course biased, as the input is derived from our customer projects or projects we know about. However, looking at those:

Some projects directly aim at a pure web-based solution, typically, if they benefit a lot from the advantages, if they implement something from scratch and if they have a pretty self-contained feature set (e.g. training).

Few projects do not consider web-based tooling at all, mostly if they have a defined set of continuous users and a lot of existing investments in their desktop tools.

Most projects plan to maintain their desktop solutions in the near future, but will migrate certain use cases to web technology. Therefore, those projects implement certain design patterns allowing this partial migration. We will highlight how to develop a strategy and useful patterns to apply in this follow-up article. Follow us on Twitter to get notified about further blog posts on this topic.

Finally, if you are dealing with the designing decision in your project and want support, if you want an evaluation of a web-based version of your tools or if you want to make your current tools ready for the upcoming challenges and chances, please do not hesitate to contact us. Among other vendors EclipseSource provides you with support for tool projects. With our focus on creating tools, we combine experts for web- and cloud-based tools together with Eclipse, DSL, IDE and modeling experts. Please have a look at our service offering for web-based tools or tools in general. Please get in contact with us, in case you have any questions or want to learn more about how we can support you.