Eclipse Two: “I want to use Electron as a vehicle to rethink the IDE experience”
Doug Schaefer, Eclipse CDT project co-lead announced in a blog post that he is working on Eclipse Two, “the real next-generation Eclipse IDE based on Electron.” The announcement sparked a lot of questions, so we decided to invite him to talk about Eclipse Two and what this project means in relation to the “good old” Eclipse IDE.
JAXenter: You are an Eclipse community veteran and project lead of the C/C++ Development Tools (CDT). From the perspective of a C/C++ developer, what advantages does the Eclipse IDE have over other integrated development environments?
Doug Schaefer: Other than the great features that we offer in the CDT that other IDEs try to keep up with, such as rich content assist and source navigation, as well as a great debugging experience, it really is the ecosystem of plugins that Eclipse offers that makes Eclipse such a popular IDE with C/C++ developers. They need good source management integration and plug-ins like EGit and the Subversion plug-ins offer that.
They are often working with other languages, especially as they venture into the world of the Internet of Things. Being able to develop both the server side and the embedded side of an IoT system using different languages but the same tools allows developers to work on the full stack much more easily.
Being able to augment their systems with domain specific languages, it is valuable to be able to have full IDE capability thanks to Xtext. And the systems that C/C++ developers work with tend to be very complex which leads them to be one of the first communities to adopt modeling and Eclipse has such rich modeling plug-ins.
I had hopes for JavaFX, but I haven’t seen the Java community galvanize around it as a desktop GUI framework of the future.
And, of course, not to mention the ability for C/C++ developers to build their own plug-ins to customize their IDE and provide features specific to their environments, that would be very difficult with other IDEs, especially those that don’t publish their APIs.
Having this rich ecosystem comes from having a strong open community that isn’t under any single vendor control making it free for anyone to contribute and extend.
JAXenter: In your blog post, you announced that you are actively working on “Eclipse Two”; its goal was communicated quite clearly — to become the official successor of the “classic” Eclipse IDE. Why do you think this step is necessary?
Doug Schaefer: Well, the goal is really to explore a possible successor. The community will decide whether this new work is worthy of being that successor.
Eclipse Two started out of a thought exercise where I tried to see where Eclipse would be in five or 10 years. I think we are severely handcuffed by SWT if we want to be able to provide rich visualizations. I had hopes for JavaFX, but I haven’t seen the Java community galvanize around it as a desktop GUI framework of the future. And that led me to wonder about the future of Java as a desktop application environment and whether other technologies might offer us that.
I don’t consider Eclipse Two to be a web IDE.
And that led me to Electron, which is also used by the Visual Studio Code and Atom editors. I want to see if we could build a full IDE based on the Chromium browser and node.js that make up Electron. And while doing so, I want to use it as a vehicle to rethink the IDE experience and grow past the 1990’s style desktop paradigms that are the foundations of the Eclipse “classic” IDE. It’s really fun to think of what you would do if you could do it all over again, and this is the opportunity to do that.
JAXenter: What are the advantages of building Eclipse as a web IDE, based on technologies like Chromium and node.js (Electron)?
Doug Schaefer: Actually, I don’t consider Eclipse Two to be a web IDE. My focus is just on using the HTML DOM APIs as a GUI framework for a desktop IDE. Electron is very good at that. It offers a well-defined browser environment since it includes the browser. It also offers native environment integration thanks to the node.js APIs. It allows us to leverage the complete catalog of libraries that are on npm. It really gives us everything we need to provide a modern user experience while allowing us to integrate with the tools and service developers expect.
What’s especially exciting about this direction is the community of developers familiar with these technologies is huge. Our biggest challenge with the “classic” Eclipse IDE is finding people who know Java and are proficient with Eclipse’s workbench architecture. And that is especially true in the C/C++ community. Web technologies are prolific, and you even see them in the embedded products with HTML-driven displays or browser based visualization of embedded systems. To have such a large community to draw contributions from will breathe new life into the Eclipse community.
JAXenter: The Language Server Protocol (LSP) will be used to make Eclipse Two polyglot. In your opinion, is the LSP the future of language support in all the development environments or are there other competitive technologies?
Doug Schaefer: The Language Server Protocol effort is the first one I’ve seen that truly reaches out to all developers to participate. Microsoft is very open to adding extensions to the protocol as different language server providers and client front ends saw the need and that has really made us interested in it from the Eclipse CDT side of things. That openness will foster an ecosystem of language servers that we will be able to leverage, not only with Eclipse Two but with the Eclipse “classic” IDE as well.
JAXenter: Your project Eclipse Two makes use of the advertising phrase „The real next-generation Eclipse IDE based on Electron“; this reminds us of Eclipse Che. In which way is Eclipse Two different from comparable IDEs like Eclipse Che or Eclipse Orion that are also making use of a web editor?
I understand the need for such server based architectures for IDEs. I don’t think they’ll be mainstream. For one reason or another, most developers feel secure having the source code they’re working with on the hard drives of the machines on their desks. I firmly believe that this will go mainstream in the foreseeable feature and we need to make sure we’re providing those developers with the best IDE current desktop application technologies allow.
JAXenter: In your blog post, you also talk about your intention to develop Eclipse Two with the Eclipse community. What are the odds of Eclipse Two being accepted as an official Eclipse project and being developed by the community?
Doug Schaefer: If Eclipse Two is to ever release for the general public to use, it has to be done with the help of the Eclipse community. I don’t have the resources to do this myself. Neither does my employer. It will become an Eclipse project or I’ll stop working on it.
Our biggest challenge with the “classic” Eclipse IDE is finding people who know Java and are proficient with Eclipse’s workbench architecture.
But as of now, I’ve had a lot of people express interest, ask questions, and provide suggestions for Eclipse Two. I think it’s a very exciting technology and fun to work with. I expect Eclipse Two, or at least something very similar, to build up a community quite quickly.
JAXenter: The Eclipse IDE is a big platform for a lot of toolings and applications. Will Eclipse Two still be compatible with existing plug-ins and tools?
Doug Schaefer: I think things like the Language Server Protocol offer a path to reuse components of the Eclipse “classic” IDE. We see an effort led by Red Hat on building a Java language server based on JDT, and efforts are underway by the CDT community to build a LSP provider for C/C++. Those will certainly be reused by Eclipse Two. There is a node module that lets you run a JVM in process and provides an interface to it. I can see that being used to provide access to other Eclipse plug-ins. People have expressed interest in using Eclipse RAP as a mechanism to reuse the UI from Eclipse plug-ins.
That being said, it will be difficult to do such integrations cleanly and with a great user experience so I’m not sure how much reuse is practically possible. But I expect the community to surprise me.
JAXenter: How long will it take (approximately) for the new IDE to be in a state that allows developers to use it in their projects?
Doug Schaefer: That really depends on the community. My first phase is to support self-hosted development at which point I’ll start setting up the Eclipse project. Then we’ll see how much momentum it builds.
I started this work looking forward five to 10 years. My hope is to have the IDE ready for adoption by the five-year mark. It could happen much earlier if the community makes it happen. For now, we still have many years of life left in the Eclipse “classic” IDE even after this and we will also continue to make sure it works well for the vendors that rely on it and the users who use it daily.
Thank you very much!