特点：

Theia的模块化允许定制。
Theia被设计成在桌面和云端运行
Theia是在一个独立于供应商的开源基金会下开发的。

支持JavaScript, Java, Python ...

Theia建立在语言服务器协议上，受益于超过60个可用语言服务器的不断增长的生态系统，为所有主要的编程语言提供智能编辑支持。

集成终端

Theia集成了一个功能齐全的终端，可以在浏览器重新加载时重新连接以保持完整的历史记录。

灵活布局

Theia的shell基于[PhosphorJS]，这为可拖拽的程序坞布局提供了可靠的基础。

Eclipse Theia指南

Eclipse Theia是一个云和桌面IDE框架，它结合了经典Eclipse IDE的最佳部分和流行的VS代码编辑器。它可以部署为本地桌面应用程序，也可以部署为基于浏览器的IDE。Theia项目是Eclipse云开发(ECD)小组最新添加的，它完全是用TypeScript编写的。
乍一看，这种体系结构和技术的变化可能看起来像一个陡峭的学习曲线，但仔细一看，Eclipse平台与其新的基于web的替代方案之间有许多相似之处。在接下来的文章中，我将介绍从Eclipse插件开发中了解的一些更重要的构建块，并解释Theia中的等价概念。除了显著的共同点我将指出存在的一些不同，将帮助你深刻理解Theia如何工作。

应用程序外壳→Eclipse工作台窗口

让我们从显而易见的开始:当你启动一个Theia应用程序时，首先看到的是Theia开发者所称的应用程序外壳。与Eclipse工作台类似，它提供了以编程方式或通过用户交互(即拖放)来布局所包含的构建块的方法。

面板

标准的Theia shell由一个主区域组成，它类似于Eclipse中的编辑器区域。此外，外壳有三个可折叠的面板:左，右和底部。这些类型的面板可以包含任意数量的小部件，这些小部件在选项卡中排序，支持将它们类似于Eclipse选项卡组进行分割。

无透视

Theia不支持透视的概念。毕竟，它们从未真正被Eclipse社区以外的人所采用，而且很多人都不喜欢它们。但是由于Theia是一个开放的平台，所以可以很容易地添加对透视图的支持。作为一名开发人员，我需要管理多个应用程序外壳布局，并提供在这些布局之间切换的方法，并允许其他人参与其中。
Theia在每个工作空间的会话之间存储shell的布局。如果没有以前的布局存在，扩展可以有助于' initialLayout '。

窗体小部件→Eclipse视图/编辑器

面板和主区域中包含的元素称为窗体小部件。Theia对编辑器的处理方式与应用程序外壳视图的处理方式相同。这样您就可以在面板和主区域中自由地安排编辑器和视图。

单例小部件→视图

那些应该最多只打开一次的小部件，如文件导航器或git小部件，被称为单例小部件或在Eclipse中简单地称为视图。实现这样的窗体小部件非常简单，Theia提供了一个方便的基类“AbstractViewContribution”。
这些小部件中的UI通常使用React实现。但是Theia并没有强加任何特殊的JavaScript框架来允许重用所有的JavaScript库。

编辑器

在Theia和Eclipse编辑器之间没有太多区别。Theia嵌入了VS代码的Monaco编辑器，并将其封装在一个薄API中，这样其他基于web的编辑器小部件也可以使用。通常通过语言服务器协议(LSP)提供语言支持，但是也有其他API可用。例如，可以使用复杂的内联小部件装饰编辑器。下面是来自gitpod的截图。io是GitHub的一个在线IDE，它集成了代码评审，因此允许在编辑器中内联注释。

命令

Theia中的命令是用户在IDE中运行一些代码的一种方式。它类似于Eclipse命令，因为它有惟一的id和名称。没有类别之类的东西，也始终只有一个实现命令的处理程序。根据上下文，极少数情况下（复制/粘贴）同一命令需要多个不同的实现，通过这些处理程序中的特定贡献点解决了这种情况。

快捷键

快捷键非常重要，特别是对于开发人员工具。Theia提供了一个快捷键注册表，其中可以注册命令的快捷键。每个工作区或每个用户都可以重新配置快捷键。
KeybindingContext相当于Eclipse IDE中的上下文。它允许在某些情况下启用或禁用快捷键。可以重用KeybindingContext，它由一个函数组成，该函数实现上下文是否处于活动状态。与Eclipse IDE不同，在其声明中没有上下文层次结构，因为可以通过从另一个上下文中调用更粗粒度的上下文轻松地对其进行建模。

菜单

除了讨论命令和快捷键，我们还需要介绍菜单组件。菜单使用路径在中央菜单注册表中注册。路径由一系列id(字符串)组成，其中第一个段表示子菜单的一部分。例如，主菜单栏是用id“menubar”定义的。如果你想提供一个菜单项到编辑器的上下文菜单，你可以从id 'editor_context_menu'开始你的菜单提供路径。任何视图都可以添加新的顶级菜单路径，从而允许其他扩展对该菜单进行贡献。
其他段指向那些菜单中包含的组。其顺序基于同一级别上的id的文本顺序。这就是为什么组id通常以数字开头。例如，如果你想在主菜单的文件菜单的开放部分提供一个项目，路径将是:

export const MY_PATH = ['menubar', '1_file', '3_close', 'my_item'];

但是不要担心，你可以并且应该经常使用一些常量。
菜单项指向命令id，可选的菜单项具有回调函数，用于指示其启用状态和是否可见。

Theia扩展→Eclipse插件

Eclipse平台和Eclipse Theia之间的另一个共同点是扩展模型。与经典的Eclipse IDE一样，Theia应用程序是扩展的组合。在将Eclipse插件打包为OSGi包的地方，Theia扩展是通过npm包提供的。这使得我们可以重新利用生态系统和现有的技术。Theia扩展可以提供完整的IDE体验并使用任何api。这允许构建定制的白色标记产品，就像Eclipse社区多年来使用Eclipse平台所做的那样。

没有plugin.xml

Theia应用程序是由inversify.js组成的，这是一个用TypeScript编写的流行的依赖注入框架。每个扩展都可以通过在package.json中列出所谓的模块来提供贡献。这是惟一需要的配置文件。
Eclipse中的plugin.xml主要用于允许延迟加载插件。其思想是，您可以安装大量的插件，它们将以声明的方式贡献给UI和扩展点。只有当用户实际使用这些声明性UI组件之一时，插件才会启动。编程模型导致难以开发和维护大型的XML文件。交叉引用是通过id完成的，甚至还有某种表达式语言可以通过XML定义上下文和其他内容。
对于Theia来说，我们发现这是一个太大的折衷，特别是因为在实践中，大多数插件都是迟早要加载的。
因此，在典型的Eclipse插件中在plugin.xml中完成的所有工作都是在Theia的情况下直接在代码中完成的，从而减少了“代码”，从而更好地集成并得到更好的工具支持。

插件的解决方案

正确的插件解决方案和为用户提供可理解的错误消息(以防他们安装的插件发生冲突)给许多开发人员和用户带来了巨大的麻烦。p2算法已经做了很多工作，但是在配置冲突的情况下，用户经常会遇到令人困惑的错误消息。
由于Theia扩展遵循相同的思想，所以底层的问题(解决基于所有语义版本约束的扩展工作集)是相同的。

VS代码扩展

VS代码通过在一个约束沙箱模型中运行扩展并为所有扩展提供一个API来改善这种情况。因此，与我们在Eclipse或强大的Theia扩展中所拥有的大型复杂依赖关系图不同，大多数扩展对VS代码API只有一个依赖关系。所以在VS代码的情况下，依赖关系图通常是一个简单的深度树。主VS代码API保持向后兼容。
VS代码扩展不是在与主应用程序相同的线程/进程中执行，而是在它们自己的沙箱(工作程序)中执行。因此，如果它们崩溃了，它们不会像Eclipse插件或Theia扩展那样破坏整个应用程序。
这听起来很好，但是有一个显著的缺点:扩展所能做的一切都需要通过这个API显式地公开。这意味着在能力和灵活性方面有很多限制。例如，在VS代码中，您不能提供完整的新视图；只支持树和HTML。

Theia支持VS代码扩展

单一API还有另一个优点:它对实际实现进行了抽象。Theia已经支持LSP和调试适配器协议(DAP)，两者都是通过协议连接编辑器独立功能的手段。语言服务器和调试适配器可以用任何语言实现，因为它们在自己的进程中运行，并且只能通过JSON-RPC连接进行通信。VS代码的扩展API非常类似，但是要大得多。
长话短说，Theia将很快支持两种扩展方式：

Theia扩展:提供充分的灵活性和集成，允许任意更改和贡献。

VS代码扩展:功能没那么强大，但是在运行时安装更安全，实现更简单。