What Theia is all about — A classic IDE built with modern technology
Theia is a cloud and desktop IDE framework implemented in TypeScript. We invited Sven Efftinge, Xtext lead and co-founder at TypeFox, to explain the motivation behind it and how its scope is unique compared to existing open-source projects.
JAXenter: You recently announced the availability of Theia, an IDE for Desktop and the cloud. Could you please explain the basic aspects of the development environment?
Sven Efftinge: First of all, as you already mentioned, Theia targets both desktop and browser-based IDEs. With that, it is a suitable platform for building traditional desktop IDEs like Eclipse or IntelliJ IDEA but also browser-based development tools like Eclipse Che’s IDE, Eclipse Orion or Cloud9.
Container-based software development has become a reality for many engineers and will become even more important in the future. It offers many advantages over the traditional approach, where every developer turns their own machine into the development and runtime platform for all the projects she is working on. As opposed to that, container-based development allows for truly reproducible and reusable setups.
Coders don’t want to deal with bloated UI dialogs to configure their tools but prefer editing text as long as there is some smart editing support.
Still, usability-wise, browser-based applications sometime lack the native feel and integration that professionals ask for. Theia’s architecture is designed to meet those demands: a local tool that runs as a native desktop app (or in any modern browser) connected with one (or more) backends that can run either locally or remotely, e.g. in containers.
JAXenter: What are the differences between a “classic” IDE like IntelliJ IDEA or the Eclipse IDE and Theia and what are the similarities?
Sven Efftinge: One important difference is that Theia uses a modern UI technology. Both Eclipse and IntelliJ IDEA are based on old Java UI technologies (Swing resp. SWT) that are no longer actively maintained. Within the Eclipse community, there have been several efforts to overcome this problem already. Neither of them really got enough momentum.
Besides the fact that Theia is built on state-of-art technologies, we are trying to follow another trending principal; do not try to implement every single feature right into it, but instead leverages existing tools like linters, debuggers, transpilers and so on. It really depends on the targeted users. Coders don’t want to deal with bloated UI dialogs to configure their tools but prefer editing text as long as there is some smart editing support.
JAXenter: Visual Studio Code, Eclipse Che, Eclipse Orion, Atom — what does Theia have in common with these IDEs, and how is it different from all these IDEs?
Sven Efftinge: Before we began working on Theia, we had several discussions with developers of all the tools you have mentioned. Our initial plan was to find an existing, well maintained, open-source project that we could adjust to our requirements via contributions. Let me go through the projects one by one and explain how Theia is different.
Eclipse Orion has started a couple of years ago, targeting web application development in browsers. The extension system was designed to be very secure, which comes at the cost of flexibility. Eclipse Orion provides a really good code editor widget, which we could have reused, but Microsoft’s Monaco editor is currently the better choice for us, because of the native support for the language server protocol and because it is implemented in TypeScript.
Eclipse Che, in fact, consists of two major parts: A workspace management server and an IDE that runs in the browser. The Eclipse Che IDE comes with a couple of good features and architectural choices, but it is implemented in Java using GWT, which imposes a lot of complexity and long turnarounds. Also, it is coupled with the workspace server, which wouldn’t allow to use it in other environments not to mention a desktop version of it. Theia is a substitute for the IDE part but will run smoothly with the Che workspace server.
The Language Server Protocol is a central aspect of Theia and nicely shows that IDEs and compilers are built a bit differently today.
JAXenter: What role does the Language Server Protocol play in Theia?
Sven Efftinge: The LSP is a central aspect of Theia and nicely shows that IDEs and compilers are built a bit differently today. In the past, an IDE like Eclipse would have implemented the full language support specifically for the tool. This not only means a lot of development effort but also a lot of duplication because a lot of the semantics that decent language support is built on, is already implemented in the language’s compiler. The LSP allows
The LSP allows reusing that logic, by connecting to and reusing the compiler directly. Of course, such a compiler needs to deal additional requirements like incremental and often broken state changes. But modern compilers like the one from TypeScript or any Xtext-based one do this quite elegantly.
JAXenter: For Theia, you rely heavily on TypeScript. Why is that?
JAXenter: Let’s talk use cases. For which kind of applications is Theia especially useful, for which is it not?
Sven Efftinge: Theia can be used as the foundation for any engineering tool. At its core, it really is an RCP framework that supports desktop and browser apps. It follows the single-page app design and comes with rich layouting, an extension system and other general features like a command registry and the corresponding menu and keybinding services.
While Theia will be the basis of development tools similar to today’s IntelliJ IDEA or Eclipse IDE, it also supports less code-centric software tools for engineers. The Eclipse RCP framework has been used for many such applications, Theia aims to provide a future-proof foundation for such products as well.
Today, in many cases, it is desirable to provide such tools as native desktop apps as well as browser apps served from cloud services. Most development setups are very complex and a container approach really eases setting up and reusing such environments, while a browser IDE allows developers to access those containers. Eclipse Che really hit a sweet spot here, with Theia we want to contribute to it with a modern IDE.
JAXenter: What are your plans for the Theia project?
Sven Efftinge: First, it is important to understand that this is not a solo TypeFox project, but that we just provide the initial draft of what shall be collaborative and open effort between multiple parties. The whole thing started with some discussions and email exchanges and really kicked off with a meeting we had in San Jose back in March. Participants from Ericsson, Codenvy, Intel, Obeo, RedHat and TypeFox were discussing the demands and scope of such a project.
We have started to implement the core framework once I came back from the states. We wanted to put something concrete in place, as it is very hard to design a coherent framework in a bigger committee.
IDEs need to be fast and get out of your way to allow the user to focus on the actual work.
Now that the initial draft has been laid out, we made it public to get more participants and contributors in. Developers from Ericsson already work on a preferences system and are going to start working on the debugger integration, which makes a lot of sense as they have been working on CDT’s debugging interface and GDB as well.
TypeFox will keep working on many different topics, like basic Git integration and the extension registry. The ability to build, publish and consume extensions is the key to grow an ecosystem and allow more people to participate and build interesting stuff with Theia. We want to make this very easy.
JAXenter: Do you think the classic IDEs are on the brink of extinction?
Sven Efftinge: Actually, to me, Theia is a classic IDE built with modern technology. The technology stack is really a big problem for the big IDEs like Eclipse, IntelliJ, Netbeans but also the classical Visual Studio, because in the future more and more organizations will need to provide their development environments from cloud services, too.
Besides, I think that IDEs need to be fast and get out of your way to allow the user to focus on the actual work. Over the years, some IDEs might have grown a bit too fat and bloated so that sometimes users suffered from them. That should, of course, be avoided, but I guess this is not a new insight.