跳转到内容
Jason's Study

Atom — 已归档的 Web 编辑器先驱

是什么

Atom 是 GitHub 于 2014 年开源的文本编辑器：用 HTML、CSS、JavaScript 写的，运行在 Electron（一层把 Chromium + Node.js 打包成桌面应用的框架）里。

日常类比：

  • 普通桌面软件像用砖头盖的房子——改一堵墙要懂建筑结构，没入门很难动。
  • Atom 像用乐高搭的房子——墙是一个 <div>，颜色是 CSS，按钮行为是 JavaScript，前端开发者拿起来就能改。
  • 代价是：乐高房子比砖房轻一点，但启动要先把整个玩具盒打开——Chromium 引擎比 Vim 重得多。

Atom 是第一个把”浏览器内核 = 编辑器渲染层”这条路走通并开源的编辑器。它孕育了 Electron 框架，Electron 又养出了 VS Code、Discord、Slack 桌面版。Atom 本身于 2022 年 12 月 15 日正式归档停止维护，但它打开的那扇门从未关上。

Terminal window
# 安装（macOS，历史性操作，仅供了解）
brew install --cask atom


# 从命令行打开当前目录
atom .

为什么重要

不了解 Atom，下面这些事很难解释清楚：

  • Electron 从哪来的——Atom 的构建框架”Atom Shell”在 2015 年独立成 Electron，如今支撑了数十款主流桌面应用
  • VS Code 为什么也用 Electron——微软 2016 年受 Atom 直接启发，做了架构更精简的 VS Code；没有 Atom 打样，VS Code 未必选这条路
  • 插件系统怎么做到”装包就能扩功能”——apm（Atom Package Manager）是 npm 的定制版，把前端生态搬进编辑器插件市场的第一个实践
  • Tree-sitter 语法解析库从哪冒出来——Atom 团队为了解决”大文件语法高亮卡顿”自研了 Tree-sitter；它现在是 Neovim、Helix 的语法解析标准

核心要点

Atom 的架构可以拆成三层：

  1. 宿主外壳（Electron）：每个 Atom 窗口是一个独立的 Chromium 浏览器进程，主进程（Node.js）负责菜单、窗口管理、文件 I/O；渲染进程负责画编辑器 UI。类比：Electron 是”把网页装进一个没地址栏的浏览器窗口”的套路。

  2. 编辑器核心（TextBuffer + TextEditor）：文档内容存在 TextBuffer 里（纯 JS 对象），光标/选区/折叠逻辑在 TextEditor 里。DOM 渲染用”只渲染可视行”的虚拟列表，勉强撑起中等文件。树形语法解析（语法高亮 + 代码折叠）由 Tree-sitter 增量更新。

  3. 插件系统（apm）：每个插件是一个 npm 包，通过 atom.commands.add、atom.workspace.observeTextEditors 等 API 挂钩到编辑器事件。包由 apm 安装，底层是 npm install 加上特权 API 访问。类比：浏览器扩展，只是运行在桌面进程而非沙箱里。

实践案例

案例 1：在 Atom 里搭前端开发环境

Terminal window
# 安装 TypeScript 语言支持插件
apm install atom-typescript


# 安装格式化插件
apm install atom-beautify


# 安装 linter 框架 + ESLint 适配
apm install linter linter-eslint

打开项目后，atom-typescript 会自动读 tsconfig.json，提供自动补全、跳转定义、内联错误标注。这是 VS Code Language Server Protocol 流行之前，让编辑器懂语言的主流方式——每个语言对应一个插件，插件自己实现分析逻辑。

与 VS Code 的对比差异：VS Code 用 LSP（语言服务器协议）把语言智能解耦成独立进程；Atom 的插件直接在渲染进程里跑分析代码，互相影响的风险更高，但早期更灵活。

案例 2：写一个最小 Atom 插件

lib/hello-world.coffee
module.exports =
  activate: ->
    atom.commands.add 'atom-workspace',
      'hello-world:greet': ->
        atom.notifications.addSuccess '你好，Atom！'
// package.json（插件元数据）
{
  "name": "hello-world",
  "main": "./lib/hello-world",
  "activationCommands": {
    "atom-workspace": ["hello-world:greet"]
  }
}

按 Cmd+Shift+P 搜索 Hello World: Greet 就会弹通知。这个模式展示了 Atom 插件系统的三要素：activate 生命周期、atom.commands.add 注册命令、atom.notifications 调用内置 API。

理解这个模式，就能理解现代 VS Code 扩展（vscode.commands.registerCommand）为什么长得几乎一样——VS Code 抄了 Atom 的 API 设计思路。

案例 3：Teletype 实时多人协作编辑

Teletype 是 Atom 内置的实时协作插件，背后用 WebRTC 建立点对点连接：

Terminal window
# 安装（Atom 1.22+ 内置，否则手动装）
apm install teletype


# 主持方：打开面板 → Share portal → 复制邀请链接
# 参与方：粘贴链接 → Join portal

多人光标实时同步，不经过中心服务器（仅 WebRTC 信令走 GitHub 服务器）。

对比 VS Code Live Share：Live Share 走微软中央服务器转发，延迟更稳定但依赖网络；Teletype 是真正的 P2P，局域网下延迟极低，但 NAT 穿透失败时连不上。Teletype 的实现在 2017 年是实时协作编辑领域很先进的工程实践。

踩过的坑

  1. 冷启动慢：Electron 每次启动要初始化完整 Chromium 渲染引擎，比 Vim/Sublime 慢 3-5 秒；装了 20+ 插件后更明显，因为每个插件都在主进程 require()。

  2. 内存占用高：空窗口 200-400 MB，开多标签 + 插件后轻易超 1 GB；低内存机（8 GB RAM）同时开多个项目会明显变卡，这是 Electron 架构的根本代价。

  3. 大文件崩溃：编辑器用 DOM 渲染行内容，10 万行以上的日志文件会让渲染进程卡死；即便有虚拟列表优化，DOM 的批量重排比纯 C++ 的 GPU 文本渲染慢一个数量级。

  4. 插件互相冲突：apm 生态开放但缺乏质量审核，插件可以随意访问内部 API；版本升级后私有 API 变了，大量插件静默失效，诊断起来只能靠一个一个禁用排查。

适用 vs 不适用场景

适用：

  • 学习 Electron 框架的工作原理，Atom 是最完整的开源参考实现
  • 理解插件化编辑器的 API 设计（命令、事件、工作区 API）
  • 研究 Tree-sitter 增量语法解析——Atom 仓库里有大量实战使用案例
  • 历史归档阅读：了解 2014-2022 年编辑器生态的演进路径

不适用：

  • 日常开发工作——Atom 已停止维护，安全漏洞不会修复
  • 大型代码库导航——没有持续投资的 LSP 支持，语言智能不如 VS Code
  • 内存/性能敏感场景——Electron 的资源开销远高于 Vim/Neovim/Helix
  • 生产环境脚本化——atom CLI 不适合 CI/CD 管道

历史小故事（可跳过）

  • 2011 年：GitHub 内部工程师开始用 Web 技术实验桌面编辑器，内部代号”Atom”。
  • 2014 年 2 月：Atom 以私测邀请制发布，开发者需排队申请，上线当天申请量超 5 万。同年开源，社区数月内贡献了数百个插件。
  • 2015 年：Atom 的构建框架”Atom Shell”正式更名为 Electron，从 Atom 项目独立出来，成为所有用 Web 技术做桌面应用的通用基础。
  • 2016 年：微软发布 VS Code，同样基于 Electron，但架构上把语言智能抽成独立进程（LSP），启动性能和内存控制明显优于 Atom。从这一年起，Atom 的市场份额开始被 VS Code 蚕食。
  • 2022 年 6 月：GitHub 宣布将资源集中于 VS Code，Atom 进入归档状态。同年 12 月 15 日，所有官方仓库锁定为只读，Atom 正式成为历史。

学到什么

  1. “用 Web 技术做桌面”是一场用开发体验换运行性能的交易——Atom 证明这条路能走通，VS Code 证明还能再优化一遍
  2. 框架往往比应用活得更长——Atom 退场了，但 Electron 还在，Tree-sitter 还在，它们影响的项目比 Atom 本身更多
  3. 开放插件 API 是双刃剑——生态爆发快，但插件质量失控、私有 API 一变全崩；LSP 的解法是用标准协议代替私有 API
  4. 归档不等于无用——作为学习 Electron 架构、插件系统设计和 WebRTC 协作实现的参考代码，Atom 的仓库依然有价值

延伸阅读

  • 官方仓库（归档）：atom/atom——完整源码，CoffeeScript + JavaScript，适合研究插件 API 设计
  • Electron 框架：electronjs.org——Atom 孵化出的框架，有完整文档
  • Tree-sitter 主页：tree-sitter.github.io——Atom 团队发明的增量语法解析库，现已独立
  • vscode —— VS Code 是 Atom 的精神继承者，理解两者差异有助于理解编辑器架构演进

关联

  • vscode —— 同样基于 Electron，LSP 架构解决了 Atom 的插件隔离难题，是编辑器生态的最终赢家
  • monaco-editor —— VS Code 的编辑器内核，可嵌入网页，Atom 的 TextEditor 是它的前辈对照
  • codemirror —— 另一条”用 Web 技术做编辑器”的路线，走浏览器内嵌而非 Electron 桌面
  • neovim —— Atom 归档后大量用户迁移到 Neovim；两者都支持 Tree-sitter，但架构哲学相反
  • helix —— 用 Tree-sitter 做语法解析的现代终端编辑器，继承了 Atom 留下的语法解析标准
  • vim —— Atom 想挑战的目标之一；轻量、快速，正是 Atom 做不到的
  • zed —— Atom 原班人马重新用 Rust 写的高性能编辑器，可视为 Atom 理想的”最终形态”

反向链接

  • codemirror —— CodeMirror — 编辑器不是一个类，是一组扩展的合奏
  • monaco-editor —— monaco-editor — 把 VSCode 编辑器搬进浏览器的 SDK
  • textmate —— TextMate — macOS 经典编辑器，语法格式影响了所有人
  • vim —— Vim — 模态编辑器之父
  • vscode —— VS Code — 把编辑/调试/扩展捏成一个跨平台壳
  • xi-editor —— xi-editor — Rope + CRDT 驱动的实验性编辑器