Back to the roots

If you were to name alternatives to the Eclipse IDE, you’d probably say “NetBeans” or “IntelliJ”. But the times they are a-changin’: Eclipse is no longer just competing with other feature-rich IDEs, but also with an increasing number of lightweight, extensible editors: Atom, Sublime, Vim, Visual Studio Code, to name only a few. The question is: Why are these editors becoming so popular?

The world of programming languages, technology stacks, and use cases is becoming increasingly diverse and differentiated, as seen in an infographic (which only covers the world of JVM languages, i.e. one ecosystem out of many!). IDEs such as Eclipse have adapted to this complexity by continuously adding functionality and tooling support, while text editors such as Atom have followed the principle “less is more”.

Thus, for developers, there are basically two options to deal with this technology fragmentation when choosing your development tools: You can go for a traditional IDE with full tool support whose functionality covers aaaaaaaalll the use cases out there. After all, the more tooling an IDE supports, the more likely it will support the tooling you actually need. But then, this might also feel like buying a big loaf of cinnamon raisin bread when all you need is a couple of raisins.

Or you choose the opposite: an MVP for software development that just provides the basics, e.g. a simple text editor with syntax highlighting. Enter Atom, Vim, etc. If you need more, there is always the option of tweaking and extending it. This requires some hacking and configuring, but it also gives you the flexibility to create a truly customized, modular, and lightweight IDE, so that you can focus on your tasks instead of being distracted by unnecessary clutter. This is, in a nutshell, what makes lightweight editors so attractive compared to full-fledged IDEs.

The more tooling an IDE supports, the more likely it will support the tooling you actually need. But then, this might also feel like buying a big loaf of cinnamon raisin bread when all you need is a couple of raisins.

Killing the noise

As you’ve probably noticed, there are quite a few projects and initiatives within the Eclipse ecosystem to improve the IDE, especially in terms of language tooling (LSP, improved Editor support, lightweight syntax highlighting with TextMate grammars) and the overall user experience (s. the Platform UI team).

But along with any effort to simplify the Eclipse UI comes the challenge of developing an overall product vision, which, in turn, is crucial for obtaining a unified, user-friendly UI. And let’s be honest: It’s close to impossible not to lose sight of the bigger picture if you’re working hard to improve details — even if every detail on its own makes a big difference. Plus, it’s close to impossible to synchronize the aforementioned projects in such a way that all the improvements are implemented within a short period of time. As a result, the complexity of the Eclipse IDE as a whole has remained largely unchanged.

The Sandbox for Eclipse

This is how we came up with the idea of a thought (and development) experiment: taking a step back and stripping the Eclipse IDE down to essentials to provide a basic building block for rethinking and rebuilding it from the ground up. So we created this barebone version of Eclipse, a Sandbox for Eclipse. The idea behind it is to gradually build a user-friendly, lightweight text editor on top of it. Missing features for decent text editing will be added step by step and based on your — the users’ — feedback. The only requirement: During the entire process, the user experience should take center stage.

The Sandbox for Eclipse editor

The Sandbox for Eclipse is based on the “Eclipse Platform IDE”, which is basically the core IDE of the Platform project. It doesn’t include JDT (Java tooling), CDT (C/C++ tooling) or the like.

Why is there no spell checker? In Eclipse, this feature is traditionally provided by JDT and thus dependent on it. Since this barebone Eclipse version doesn’t include JDT, there is no spell checking available either.

Before you can save a file in Eclipse, you need to create a project in your workspace. An easy way to install the Sandbox for Eclipse is via the following link: https://www.yatta.de/profiles/hub/sandbox-for-eclipse (pro-tip: this option will allow you to receive and easily apply updates for the Sandbox).

Here is the link to the open source project: https://github.com/YattaSolutions/eclipse-sandbox.

Please note that we will regularly update the Profile and the GitHub project based on the changes we received.

If you would like to upload your own Sandbox subproject for others to experiment with, you can do so by sending a pull request on GitHub or just forking and re-uploading the Profile. This way, the community can see and review your changes.

Join us on this development journey: Download the Sandbox for Eclipse either as a ZIP (s. also options #1 or 2 below) or as a Profile for Eclipse (option #3) and let us know how you use and extend it by leaving a comment underneath the Profile or by writing an e-mail to profiles@yatta.de

Option 1: Sandbox for Eclipse ZIP (Clicking on the link will start the download)

Option 2: Sandbox for Eclipse on GitHub

Option 3: Sandbox as Profile for Eclipse