为什么有人想换掉 VSCode 的底层？
VSCode 是目前最流行的代码编辑器，但它也有一个老问题：越用越卡。
打开几个项目窗口，内存占用轻松突破 1-2GB。在配置一般的笔记本上，风扇会转得让人心烦。更不用说它将近 800MB 的安装包——对一个编辑器来说，这个体积确实偏大。
让 VSCode 变轻，是不少开发者反复琢磨的事。最近 GitHub 上出现了一个叫 SideX 的项目，它没有选择重写整个编辑器，而是换掉了 VSCode 的底层运行时：从 Electron 换成了 Tauri。
Tauri 凭什么比 Electron 小？
要理解 SideX 的思路，得先搞清楚 Tauri 和 Electron 的区别。
Electron 的做法是每个应用都打包一份 Chromium 内核。这样做的好处是跨平台行为一致，代价也很明显：安装包大、内存占用高。VSCode 797.8MB 的安装包就是这么来的。
Tauri 走的是另一条路。它不打包浏览器内核，而是调用系统已有的 WebView 组件：macOS 上用 WKWebView（Safari 同款），Windows 上用 WebView2。这些组件系统层面已经预装了，所有 Tauri 应用共享同一份内核。
结果是安装包从 800MB 降到了 16.4MB，差了将近 50 倍。
SideX 的技术路线：移植而非重写
市面上已有的 VSCode 替代方案，比如 Zed 和 Notepad++，走的都是「从零写一个原生编辑器」的路线。SideX 选了另一条路——把 VSCode 的工作台代码直接搬过来，只换底层。
具体来说，SideX 移植了 VSCode 工作台的 5600 多个 TypeScript 文件，覆盖了大半个工作台。依赖注入、服务分层这些核心架构基本没动。变的只是运行时：Electron 主进程用 Rust 重写，Node.js 的文件读写、PTY 终端、Git 操作也全部用 Rust 实现。
苏米注：这个策略很聪明。如果从零重写，最大的障碍不是技术，而是没人能贡献代码——因为没人熟悉你的代码结构。SideX 保留了 VSCode 的代码骨架，熟悉 VSCode 扩展开发的开发者可以零门槛上手。
目前能用到什么程度？
SideX 目前的状态是「能用，但不能当主力」。
已经稳定的模块：
- Monaco 编辑器（VSCode 的核心编辑组件）
- 文件管理
- 集成终端
- Git 操作
- 主题切换
- 从 Open VSX 安装扩展
还在开发中的模块：
- 扩展宿主（Extension Host）
- 调试器
- 设置界面
扩展宿主和调试器是 IDE 最核心的功能，目前处于半成品状态。所以现阶段把它当主力编辑器用还为时尚早。
性能表现：有优势，也有不确定性
性能方面需要分平台看。
macOS 上，WKWebView 是系统级共享组件，省内存效果比较明确。作者的目标是空闲状态下内存控制在 200MB 以内。
Windows 上 WebView2 的情况更复杂一些。根据内存测量方式的不同，读数会有差异，目前还没有权威的基准测试数据。具体的性能对比，要等项目更稳定后才会公布。
如何本地构建
SideX 目前还没有预编译的二进制版本，需要从源码自行构建：
git clone https://github.com/Sidenai/sidex.git
cd sidex
npm install
npm run tauri dev首次构建需要编译 Rust 代码，大概 5-10 分钟。
苏米的看法
SideX 最有意思的地方不在于它能不能取代 VSCode，而在于它选的路径。
Zed 发布已经有一段时间了，性能确实出色，但 VSCode 的市场地位纹丝不动。根本原因不在编辑器本身，而在插件、调试器、Copilot 集成——开发者真正离不开的是 VSCode 背后的扩展生态。这才是 VSCode 的护城河。
SideX 押注的是「生态价值大于性能差距」。把生态留下，把运行时换掉，比从零搭建一个新生态要现实得多。这个赌注能不能成立，关键看扩展宿主部分后续能不能跑通。
如果能跑通，Tauri 承接大型项目的落地能力也就被验证了一次。对想学 Tauri 怎么用在大型项目上的开发者来说，SideX 现在就是个活案例。
GitHub 项目地址：https://github.com/Sidenai/sidex