我对于编辑器 Atom 一向用得很少，不过当听到 新闻: Atom 团队开发下一代高性能编辑器 Xray 时，仍然感到有点震惊。毕竟，Atom 诞生至今也不过 4 年时间，按照一般的软件生命规律，应该还是处于上升阶段，还没到变成死在沙滩上前浪的年纪。但是 Atom 团队现在就开发新一代编辑器，目的何在？

带着问题阅读 Xray 项目 介绍，可以看出一些端倪。

目标

主页的介绍开宗明义，描述了 Xray 的目标：

Xray is an experimental Electron-based text editor informed by what we've learned in the four years since the launch of Atom. In the short term, this project is a testbed for rapidly iterating on several radical ideas without risking the stability of Atom. The longer term future of the code in this repository will become clearer after a few months of progress. For now, our primary goal is to iterate rapidly and learn as much as possible.

这里有两个重点。首先，开发 Xray 是基于团队在“开发 Atom 4 年时间中学到的东西”。这证明 Xray 的目的确实是为了解决 Atom 中存在的一些问题，而且应该是比较深入的、架构层面的问题，否则对 Atom 进行重构即可，不必重开新的项目。

其次，这里也说明另开项目的原因是为了加快迭代速度、尝试新的想法，而尽量避免对原有项目的影响。这样的想法也是可以理解的。当然，这再次印证了————任何项目从创建的那一刻起就开始变成遗留（legacy）项目，即便对 Atom 这样年轻的项目也不例外。

High performance: Xray feels lightweight and responsive.

Xray 将高性能作为首要的特性。从现实看，社区和用户对于 Atom 的速度确实诟病颇多，想必开发团队的压力也很大，因此 Xray 将性能作为首要的问题。

We design features for collaborative use from the beginning. Editors and other relevant UI elements are designed to be occupied by multiple users. Interactions with the file system and other resources such as subprocesses are abstracted to work over network connections.

Xray 的野心相当大，不满足于只做个人编辑器，还想成为团队协作工具，在架构上也会使用多进程、甚至跨网络的分布式体系。设想很宏大，不过细节如何还不清楚，能走多远要看将来的发展了。

We expose convenient and powerful APIs to enable users to add non-trivial functionality to the application. We balance the power of our APIs with the ability to ensure the responsiveness, stability, and security of the application as a whole. We avoid leaking implementation details and use versioning where possible to enable a sustained rapid development without destabilizing the package ecosystem.

过去很长时间内，文本编辑器和 IDE 是泾渭分明的领域，也引发了不少“圣战”。不过最近几年，它们之间的界限似乎在模糊甚至消失：IDE 竭尽所能地变得更加灵活，而文本编辑器则尽可能地提供更多开发辅助功能，彼此之间越长越像了。也可以这样说，所有编辑器都有一颗想当IDE的心。Atom也不例外，安装包上百MB，占用空间将近 500MB，已经超过很多IDE的大小了，但它们的胃口仍然不止于此。我不知道这是好事还是坏事，总之是时代的潮流吧。

Web compatibility: Editing on GitHub feels like editing in Xray.

这也是一个有趣的想法：让网页和本地编辑器拥有相同的核心编辑器功能，在体验上也趋于一致。

架构

上图是 Xray 的核心架构。

界面: Electron

Electron adds a lot of overhead, which detracts from our top priority of high-performance. However, Electron is also the best approach that we know of to deliver a cross-platform, extensible user interface. Atom proved that developers want to add non-trivial UI elements to their editor, and we still see web technologies as the most viable way to offer them that ability. We also want to provide extension authors with a scripting API, and the JavaScript VM that ships with Electron is well suited to that task.

从上述描述可以感受到，开发团队对于 Electron 的感情可以说是“爱恨交织”。恨，因为 Electron 是性能问题的首要元凶（官方实锤）；爱则是因为团队坚信 Electron 仍然是开发跨平台、可扩展界面的最优秀的技术平台。

核心: Rust

这可能是 Xray 相对于 Atom 中最大的架构变更，恐怕也是最容易引起争论的地方：用 Rust 开发核心逻辑。

All of the core application code other than the view logic should be written in Rust. This will ensure that it has a minimal footprint to load and execute, and Rust's robust type system will help us maintain it more efficiently than dynamically typed code. A language that is fundamentally designed for multi-threading will also make it easier to exploit parallelism whenever the need arises, whereas JavaScript's single-threaded nature makes parallelism awkward and challenging.

按照上述说明，引入 Rust 的主要原因包括：

• 加载/执行的负担更轻；
• 类型系统有助于提升可维护性；
• Rust 能实现真正的并行，而 JS 的单线程特性使得并行极具挑战。

第二条是动态/静态语言多年来争论的核心问题，相关的讨论已经太多，这里就不再展开了。第三条倒是可以说说。在服务端，多线程并不是一个很好的并发模型这一点基本上已经成为共识，但客户端程序还是非常需要多线程的。虽然 Chrome 通过多进程架构避开了这个问题，但并不是每个程序都需要如此复杂的架构。Atom 开发团队尽管对 Electron 非常执着，但对 JS 的并发能力却明显透露出悲观的看法，这个现状恐怕是 JS 的拥护者所不大好接受的。

Rust 首次大规模应用是在 Firefox Quantum, 我以前也有一片文章提到这一点，现在又多了一个重量级案例，对 Rust 来说当然是个利好。不过 Rust 本身仍然是门槛相当高的语言，不太可能成为大众化的选择，这个特点并没有实质性的变化。同时，这也意味着社区向 Xray 作贡献的能力要求也更高了，不知道开发团队能否掌握好这个平衡。

文本: WebGL

In Atom, the vast majority of computation of any given frame is spent manipulating the DOM, recalculating styles, and performing layout. To achieve good text rendering performance, it is critical that we bypass this overhead and take direct control over rendering. Like Alacritty and Xi, we plan to employ OpenGL to position quads that are mapped to glyph bitmaps in a texture atlas.

Bypassing the DOM means that we'll need to implement styling and text layout ourselves. That is a high price to pay, but we think it will be worth it to bypass the performance overhead imposed by the DOM.

这里讲到了界面方面非常重要的变更。我用开发者工具看过，Atom 编辑器的文本块的确是用 DOM 元素实现的，但用 DOM 进行大量元素操作肯定会造成明显的性能问题，Atom 加载大文件卡顿甚至崩溃的现象早就屡见不鲜了。现在，开发团队打算用 WebGL 从头实现。我很佩服他们的勇气，因为正如他们自己所说，这意味着大量的工作；同时，我也对这个项目是否真的能像开发者期望的那样快速迭代，保持谨慎怀疑的态度。

那么 Atom 未来会如何？

Atom 在可预见的将来还会继续开发下去，因为 Xray 目前远远没有达到可以接班的成熟度。但开发团队的力量会更多的放到新项目中去，这是意料中的事情。从上面的分析可以看到，Xray 和 Atom 在架构上的差别相当大，可以互相参考的地方恐怕不多。并且 Xray 许多基础功能是要从头做起的，需要投入大量的人力，那么分配给 Atom 的开发力量就难以让人乐观了。这可能会让 Atom 的爱好者觉得沮丧，但是我确实觉得，Atom 很有可能成为慢慢走向死亡的项目。

Electron 仍然活的很好，它是 Atom/Xray/VSCode 的基础，也仍然是很多客户端项目的第一选择。

我在其他地方也表明过这样的观点：JavaScript 前几年借助 Nodejs，上升的势头非常猛，但它开疆拓土的领域主要集中在和 Web 结合紧密的领域，再向其他领域渗透将会相当困难。Xray 将核心用 Rust 重写，一定程度上印证了某些人鼓吹的 Javascript rules all 并不现实。那也是我乐见的结果：如果世界上只有一种语言，那么这个世界该是多么的乏味。