Lapce — 把编辑器搬到 GPU 上的 Rust 实验

是什么

Lapce 是一个用 Rust 从零写、靠 GPU 画画面的代码编辑器。日常类比：VS Code 是把网页技术（HTML/CSS）塞进一个壳里画编辑器；Lapce 跳过浏览器那一层，直接让显卡画字——就像别人开车走高速，它走专修的私人轨道。

形态上它和 VS Code 长得很像（侧边栏 + 编辑区 + 命令面板），但底层栈完全是另一套：

GUI：Floem（早期用过 Druid，2023 前后被作者团队替换成自研）
渲染：wgpu（Rust 跨平台 GPU 抽象，文字 + UI 都走显卡）
文本核：Rope（继承自 Xi-Editor，O(log n) 编辑超长文件）
插件：WASI（C / Rust / AssemblyScript 编到 WASM 跑沙箱）
远程：内置远程开发（类 VS Code Remote），配套 Lapdev 云开发环境

GitHub 38.5k+ star，Apache-2.0，作者 Dongdong Zhou（dzhou121），最新 v0.4.6（2026-01）。

为什么重要

不理解 Lapce，下面这些事都没法解释：

为什么 2020 年代还有人重新发明编辑器——VS Code 不香吗
为什么 Rust 社区会自己造一个 GUI 框架（Floem），而不是用 Tauri / egui
为什么 GPU 渲染对编辑器有意义——人眼读字又不需要 60fps
为什么”WASM 插件”这个看起来很潮的方案，其实是为了安全 + 跨语言而不是性能
云原生编辑器（Lapdev）和 GitHub Codespaces 思路差在哪

核心要点

Lapce 想解决的核心矛盾是：VS Code 功能完整但 Electron 太重，Vim 轻但门槛高。它的三板斧：

不要浏览器：抛弃 Electron，自己用 wgpu 画。换来打开速度（< 100ms 冷启动）和内存占用（< 100MB 静态）。代价：每个 widget 都要自己实现，没有 CSS 这种成熟样式系统。
不要 JS/TS 写插件：插件用 WASI 跑。任何能编到 WASM 的语言都能写插件，沙箱隔离避免 VS Code 那种”恶意插件偷 token”的问题。代价：生态小，没有 VS Code 数十万插件可用。
响应式 UI（Floem）：作者参考 SolidJS 的细粒度信号（fine-grained reactivity），让 UI 状态变化只重渲染受影响的那块。类比 React 的 diff 算法——但 Floem 不需要 diff，它知道哪个像素该重画。

三个选择合起来是一个赌注：桌面应用应不应该跳过浏览器栈。Lapce 是这条路上跑得最远的几个项目之一。

实践案例

案例 1：Floem 替代 Druid 是怎么发生的

Lapce 0.1（2021 年）用的 GUI 是 Druid（Xi-Editor 团队的产物）。但 Druid 在 2022 年进入 maintenance（维护态、不再加新特性），Xi-Editor 团队把精力转到下一代 Xilem。

Xilem 还在实验，Druid 又冻结。Lapce 团队没等，直接派生一个新 GUI 框架叫 Floem：

借鉴 SolidJS 的 signal / effect 模型
为编辑器场景优化（虚拟滚动、文本渲染、IME 输入法）
和 wgpu 深度绑定

教训：做产品依赖一个 framework，要么贡献它，要么准备好接管它。Lapce 选了后者。

案例 2：为什么编辑器需要 GPU 渲染

很多人第一反应：“编辑器又不是游戏，要 GPU 干嘛？”

实际答案有三层：

大文件流畅滚动：10 万行的日志文件，CPU 渲染卡顿明显，GPU 能维持 60fps 平滑滚
HiDPI 缩放正确：Retina 屏 2 倍像素 + 字号变化，GPU 缩字形比 CPU 快几十倍
特效便宜：选区平滑动画、光标拖尾、minimap 缩略图，GPU 是顺手的事，CPU 是负担

所以 GPU 渲染的卖点不是”快”（人眼分不出），而是**“在大文件 + 高分屏 + 多特效叠加时不掉帧”**。

案例 3：WASI 插件为什么不流行

理论上 WASI 插件比 VS Code 的 Node.js 插件好：沙箱、跨语言、启动快。但 Lapce 插件市场至今很稀。

原因：

写插件的人已经会 JS/TS（VS Code 教育出来的），让他们改用 Rust + WASM 学习成本太高
插件需要的能力（文件读写、进程、网络）WASI 还没全标准化，需要 host 一个个开口
用户基数小（几十万 vs VS Code 几千万），插件作者投入产出比低

教训：技术上更优的方案不一定能赢，生态网络效应是杀手级护城河。

案例 4：Rope 数据结构为什么继承自 Xi

Lapce 的文本核（rope）几乎原封不动从 Xi-Editor 搬过来。Rope 是把字符串切成多段、用平衡树连起来的结构：

中间插一个字符 → O(log n)，不需要把后面所有字节往后挪
跨段计算行号 / 列号 → 缓存在树节点上，单次查询 O(log n)
多人协同时给每个编辑打标签 → 树节点天然支持版本

代价：实现复杂度比”一个大数组”高 10 倍。但对编辑器是值得的——打开 100MB 日志文件、移动光标、滚动都不卡。这种”投入复杂度换长期性能”的权衡，是基础工程的典型套路。

案例 5：Lapdev 是怎么蹭 Codespaces 流量的

Lapce 团队 2024 年推出 Lapdev——基于 Lapce 远程能力的云开发环境，对标 GitHub Codespaces。卖点：

自托管（数据不出公司）
比 Codespaces 便宜（按需启停）
编辑器原生支持远程，不需要装扩展

但要打过 Codespaces 几乎不可能，因为后者绑死 GitHub 生态。Lapdev 的真实定位更像”给在意自托管 + 数据隐私的中小团队的备选”，不是大众产品。

踩过的坑

wgpu 在不同平台表现不一致：Windows DX12、macOS Metal、Linux Vulkan 都有边缘 bug，Lapce issue 区有大量”在 X 平台字体糊”的报告。GPU 抽象不是免费的。
IME 输入法适配难：中日韩输入法在 GUI 框架里都是脏活。Lapce 早期版本中文输入有各种小问题，Floem 重写后才稳。
modal editing 默认开：Lapce 默认开 vim-like modal editing（按 i 进入插入模式）。新人不知道，打开就一脸懵——以为软件坏了。后来加了 onboarding 提示。
vs Zed：2024 年起 Zed（前 Atom 团队）走类似路线（Rust + GPU + 自研 GUI gpui），但有更多资源和星标。Lapce 处于”先驱但被资源更足的同类追赶”的位置。
Druid 死了 Lapce 没死：Druid 进入 maintenance 时，依赖它的小项目大多停摆。Lapce 因为体量大到能 fork 一个新框架（Floem），活了下来。这是开源项目”幸存者偏差”——你看到的活下来的都做了痛苦的迁移。
跨平台字体渲染细节差异大：macOS 的字体子像素抗锯齿和 Linux freetype 不同，wgpu 又往中间塞一层，效果调教是无穷工作量。VS Code 用浏览器（Chromium）已经把这层吃掉，Lapce 重新背上。

适用 vs 不适用场景

适用：

想要轻量原生编辑器（< 100MB 内存）的人
Rust 开发者（lsp-rs / rust-analyzer 集成顺畅）
远程开发场景（内置 SSH，不需要装扩展）
学习 GUI / 编辑器架构的工程师

不适用：

重度依赖 VS Code 插件生态（Copilot、Live Share 都没有等价物）
团队协同实时编辑（不像 VS Code Live Share 成熟）
需要图形化调试器（断点 / 变量监视面板还在补）

学到什么

桌面应用不一定要 Electron——wgpu + Rust 能做出 < 100MB 的原生编辑器
依赖一个 framework，要做好接管的准备（Lapce 从 Druid 派生出 Floem 是被迫但正确）
GPU 渲染卖点不是快，是”大文件 + HiDPI + 特效叠加时不掉帧”
生态护城河 > 技术优越性——WASI 插件理论更好但生态没起来
Rust 桌面 GUI 还在早期——没有”标准选择”，每个项目都在赌

关联

codemirror —— 同样追求”轻 + 可拼”，但走 Web 路线
monaco-editor —— Lapce 的”对手”，Electron + TS 路线
ratatui —— Rust + 终端 UI，和 Lapce 是 Rust GUI 的两端
druid —— Lapce 0.1 用的 GUI，后被 Floem 替换
vllm —— 同样用 Rust 重写关键路径（推理 vs 编辑器）