Is Theia suitable to refactor (~rebuild) an old RCP Eclipse client application?

[gidthup]

A customer is using an Eclipse RCP based client that was initially build around 2008-2010. The application is still in use but it is time for modernization, both client and server side The client is looking for refactoring, keeping much of the functionality the same from end-user perspective, also literally...'the Perspectives'. The perspective functionality is a key requirement: Ability to manually reorganise views, layouts, stacking etc. and save them as personal preferences. Also dynamically adding new views programmatically, i.e. as result of a drill down action. What I have seen sofar in the online demos of Theia is that a lot of this functionality is there, but is Theia suitable to further extend into an end-user application (with tabular column views, graph views, graphical (scada) views, etc. So functionality not specific to an IDE.

Other frameworks like Angular, React, Vue dont support the perspective functionality that is available in Theia. There are some opensource 'grid' extensions, but that is not the same.

So my question is.. Does anyone have experience using Theia for an application that is not an IDE?

Any suggestions or pointers would be very welcome.

[msujew]

Hey @gidthup,

So my question is.. Does anyone have experience using Theia for an application that is not an IDE?

Personally, I would not recommend it. It's certainly possible, but if you don't need 95% of the feature set of Theia (i.e. all the IDE related parts), you're probably better off writing your own UI shell framework or built on top of stuff like lumino.

I would assume that you'd save time initially by building on top of Theia, but there are two major obstacles:

1. Existing abstractions in Theia: Once you need more custom-tailored behavior than what you get from the existing abstractions in Theia, you will need to rewrite the existing code anyway.
2. Breakage: Due to changing requirements, keeping up with VS Code and updated/outdated/exchanged dependencies we often have breaking changes in our releases. Building on top of Theia and trying to keep up to date with it is a relevant maintenance effort, that you likely don't want.

These, among others, will likely result in more work in the long run than just rolling your own UI app/framework.

[gidthup]

Thank you for the information Mark. Potential breakage is something I didn't consider yet as we have been using a very stable eclipse RCP for many years. The application is rather extensive (100+ screens) hence any backwards compatibility issues could result in a lot of rework.

[msujew]

Note that the breakage is something I might overstate. I've been involved in a project (see here) that makes heavy use of the override feature available through our dependency injection mechanism. In this project, things break in unexpected ways during Theia upgrades due to certain behavioral changes that were done for specific (and rather unusual) requirements.

A lot of adopters don't try to modify existing behavior, but rather add new stuff on top - what you're probably looking at as well. In those cases, breakage is usually rather limited, since we aim to keep the existing contribution APIs pretty stable.

Also, I rather enjoy controlling the backbone of my application. It's likely why I mostly work on frameworks, and not end-user applications. This is also influencing my advice for rolling your own UI layer. So don't trust me completely ;)

There's also another issue that I like to point out with regards to deployability of Theia: Since its design is rooted in the IDE space, it is built with the expectation that there's one instance of the app per user. This is usually no problem if you're building a desktop Electron tool, but becomes a bit resource intensive if you plan to deploy a browser app. There are ways in theory to make Theia multi-tenant capable, but it's fairly complex.

[sdirix]

I don't believe Theia is exclusively suited for IDE-like applications. While Theia is undoubtedly designed with IDE use cases in mind, its modular architecture makes it a robust platform for building a wide variety of applications that aren't traditional IDEs. We've successfully built non-IDE applications using Theia, and here are some reasons why it makes sense:

• Theia provides out-of-the-box support for running applications in both browser and Electron environments, making it easy to build cross-platform solutions.
• Theia supports plugins and VS Code extensions, enabling you to reuse the vast ecosystem of existing VS Code extensions. You can also develop a custom extension mechanism using the same architecture, allowing 3-rd party extension support
• The Theia UI layer is designed to be minimal, allowing you to build custom, framework-agnostic UIs with only a thin integration layer for Theia.
• Features such as notifications, commands, keybindings, and preferences are broadly useful and can add value to a wide range of applications, even those that don’t resemble traditional IDEs.

Note that Theia does not have a built-in perspective mechanism (in the sense of the Eclipse RCP), i.e. that is something which you have to develop on your own then. See also (#14577)

Therefore even if your application doesn’t look like a typical IDE, it can still benefit significantly from Theia’s rich feature set. However, it's important to recognize that not every application will benefit to the same degree. If most of these features are irrelevant to your use case, Theia might not be the best fit.

Using Theia comes with certain trade-offs:

• You’ll need to invest time in understanding the framework, its RPC mechanisms, and its reliance on Inversify.js for dependency injection.
• Theia’s core is relatively large, and even if you don’t need and hide some features (e.g., Monaco), they’ll still be included, which could add unnecessary overhead.

If you’re considering Theia, I recommend building a proof of concept (POC) to better understand its strengths and limitations. This will help you determine if it aligns with your needs.

Since you plan to write a lot of code from scratch, I suggest designing it to be largely agnostic of Theia (or any specific framework). By keeping your code decoupled and modular, you’ll retain flexibility:

• Allows you to reuse much of your code if you decide to switch frameworks later.
• Enables your code to run in various environments, such as frontend, backend, WebWorker, WebView, VS Code extensions, and more.

[gidthup]

Thank you Stefan. That are good points we have to consider. We plan to do a POC early next year, so this will help us to focus on subjects that will determine if Theia brings in our case.