如何評價GitHub準備推出下一代文本編輯器Xray？

項目地址: atom/xray

我們不要提下一代編輯器，就來談談這一代編輯器，並且看看有哪些優點和值得改進的地方。然後再看「下一代編輯器」的定義的含金量。

首先就是進程分離。這個事情早就被 Eclipse 證明了要想保證用戶體驗，選擇進程分離是非常重要的手段。Erich Gamma 和 Kai Maetzel 從開發 Eclipse 的過程中得到的經驗，實踐在了 VSCode/Monaco 上（2011 年開始）。Xi 和 Xray 也選擇了這條道路，這點上我挺看好的。

第二是性能瓶頸。Atom/Brackets/VSCode，都是基於 JavaScript/HTML/CSS。Xi 和 Xray 都提到了使用 C/Cpp/Rust 開發 editor core，並且他們也嘗試著合作。但就其最終目標（比如 Xi 的 160 fps ）而言，core 是不是用 C/Cpp/Rust 寫的不是很重要。最重要的原因是，現在限制刷新率和反饋速度的完全就是 rendering。用戶輸入一個字元，JavaScript 操作 text model 花了幾十幾百 micro second，連 1ms 都不到，HTML 構建加渲染（ incremental 增量更新）花了 10/20 ms，你說把 core 用 Rust/Cpp 替換掉 JavaScript 可能並不能解決問題。性能優化當然是現優化最大頭啊。

就這一代編輯器而言（我們權且把還沒實現好的編輯器當作下一代），進程分離已經成為主流思想，渲染是瓶頸也已經是共識。

如果說下一代編輯器（end to end）的最重要特徵是性能的話，那麼就不能是 Cpp/Rust + Electron 。Xi editor 的作者 Raph Levien 替 Xi-core 實現了 macOS native 的前端，benchmark fps 達到 120，就這個他都覺得太慢了，打算自己手擼渲染引擎。

如果下一代的特徵需要是 hackable，那 Atom 的最初選擇又似乎是對的。

@韋易笑 老師，我覺得要實現一個高性能和富功能的編輯器核心，並不一定需要用 native language。V8 做的非常好，而且優化也是有科學方法的。前段時間 Firefox 把他們 Sourcemap parsing 的代碼用 Rust 重寫編譯成 Web Assembly，戲能提高五倍，我們都覺得太吊了。結果 V8/Dart VM 的核心開發 Vyacheslav Egorov 通過優化演算法、優化 callstack 等常規手段，直接將原先的 JavaScript 代碼優化到比 Web Assembly 版本更快 Maybe you dont need Rust and WASM to speed up your JS 。老師可以試試使用 OniVim，就是 NeoVim + Electron，性能其實...

簡言之，實現高性能 editor core 這件事情，是可以用 JavaScript 來實現的，並不一定要全面推向 native。

還有啊，解決問題，當然是要先找 bottleneck 啦，別迷信，散彈槍式編程法在這裡沒用。

下一代編輯器的方向就是進程分離：使用 C/Cpp/Rust 開發的核心 + Electron / Qt 開發界面

這就是 NeoVim 這幾年走出來的路，界面這種東西更新迭代快，需要跨平台，需要好看，緊跟當下流行風格。用 Cpp 顯然是一件很勞累的事情，所以 NeoVim 做的最主要的事情就是把界面給 externalize 化，C 只實現文本編輯和腳本系統這些非界面的事情，界面部分讓另外一個進程來做，界面進程通過管道+msgpack 來和內核進程通信，界面進程會把用戶的操作指令發送給編輯器內核進程，編輯器內核進程又會將需要顯示些什麼發送給外部進程，由外部進程顯示出來。

由此，編輯器內核只關注性能和功能，而外部界面進程就著重跨平台和用戶體驗。

Atom 真的是成也 Electron ，敗也 Electron。用 Electron 開發內核，開發是容易了，但是結果大家都看到了。事實證明 Electron 並不擅長做編輯器內核這種一定複雜度又要求性能的東西，即便多次的把各種東西由 electron 挪到 Cpp 中，也是徒勞的。

所以 NeoVim 的實踐結果告訴大家，編輯器內核和界面，兩種完全不同的開發模式，不能混為一談。所以自 NeoVim 發布後，已經有 22 種 運行再不同操作系統下的 GUI 前端了，我自己用的就是一款用 Electron 開發的 GUI 前端：

無獨有偶，google 也開發了一個 rust 做核心，使用json進行進程間通信的編輯器：

github.com

xi-editor 使用 python 作為腳本系統，目前已經開發近兩年，完善程度比 github 的 xray 高不少，而且目前有 9種 不同的 GUI 前端，包括文本終端模式和桌面 GUI 模式。

Github 對文本編輯器的「不妥協」的探索精神是令人敬佩的，瞅了一眼它的開發者都是以前 Atom 的核心團隊，希望他們能充分吸取 Atom 的經驗給大家好好打造一款趁手的編輯器吧。

頭腦不清楚的典型。目標解決的是別人早就解決/根本不存在的問題。

「性能是賣點」根本不成立。Atom的性能爛，不代表所有Electron based editor都慢，更不要說原生語言寫出來的軟體。現代軟體處理字元串都可以不用Rope這類特殊數據結構直接拿數組硬懟，中小文件一般都不是性能問題了。

另外一個賣點是能讓插件獨立操作文本。這個需求也不是痛點。編輯器里沒有那麼多並發改文件的場景。一段文本改動往往觸發自用戶一個動作。就算真的是一個動作要觸發多個插件……對不起，社區寫不出那麼多理解代碼真正好用的插件。這才是現代編輯器最大的痛點。

現代編輯器的痛點是怎麼理解程序語言。怎麼高效地重命名，找定義，找使用，自動重構（在大項目中非常困難）。也就是操作的並不只是「文本」，更多是「代碼」。現代編輯器要解決的是怎麼提供一套強大，彈性的編輯器介面給語言實現者，怎麼給語言實現者提供通用的服務如文件變化更新，用戶輸入，代碼補全事件等等。這些事情Sublime/TextMate等一票原聲編輯器都沒做好，提供的介面太過底層。但是Atom團隊完全沒把這個事情放在設計目標里。

當然Xray好像還有其他暗搓搓的目標。比如核心用到的CRDT數據結構可以支持多人在線編輯，Rust+Electron+React的技術選型很容易挪到瀏覽器端（如果WASM一切安好）。

怕不是以後要給同性交友網站添加在線攪基功能。