共计 3300 个字符，预计需要花费 9 分钟才能阅读完成。
最近在研究桌面应用开发框架的时候，偶然看到了 Electrobun 这个项目，一下子就被它的设计思路吸引了。作为一个用过 Electron 开发过小工具、也关注过 Tauri 发展的人，我对这个领域的痛点相当熟悉：Electron 打出来的包动辄一两百兆，启动的时候要等那么一两秒，内存也吃得很凶；Tauri 虽然解决了打包体积的问题，但主进程用 Rust 写，对很多前端开发者来说有相当陡峭的学习曲线。[[Electrobun]] 的出现，让我看到了另一条路。
为什么桌面应用开发一直是个难题
谈 Electrobun 之前，我们得先说说这个问题的背景。桌面应用开发长期以来有两种主流路线：一种是用原生语言（Swift、Objective-C、C++、C#）写，性能和体验都好，但开发效率低，跨平台也是个噩梦；另一种就是 Web 技术栈——用 HTML、CSS、JavaScript 来构建 UI，通过某种桥接层运行在桌面上。Electron 在 2013 年横空出世，彻底打通了这条路，让 VS Code、Slack、Discord 这些产品得以用 Web 技术栈快速迭代。但 Electron 的代价也是公认的，它把整个 Chromium 浏览器引擎打包进每一个应用，导致随便一个 Electron 应用安装包就是 150MB 起步，运行时内存轻松占到几百兆。
Tauri 在 2022 年前后成了大家谈论的替代品。它的核心思路是：既然操作系统本身已经有了浏览器引擎（macOS 上的 WebKit，Windows 上的 Edge WebView2），何必再打包一个 Chromium？Tauri 就是这么做的，渲染层直接用系统 WebView，应用体积一下子降到了几兆。但 Tauri 选择用 Rust 写后端逻辑，这对熟悉 TypeScript 的前端开发者来说，又制造了一道新的门槛。你要写 Rust，你要理解所有权和生命周期，你要学习一个与以往截然不同的编程范式。不是说 Rust 不好，只是它确实需要时间。
Electrobun 的基本思路
Electrobun 是由 Blackboard Technologies 开发的一个新框架，GitHub 上已经积累了接近 5000 个 Star，在 2024 年底正式发布了 1.0 稳定版。它的核心定位是：全程 TypeScript，不妥协性能，不打包 Chromium。
具体来说，Electrobun 把应用拆成几个关键层。主进程不用 Node.js，而是用 Bun 来运行 TypeScript——这个选择很有意思，Bun 本身就是一个高性能的 JavaScript 运行时，内置了打包器和测试框架，启动速度比 Node.js 快很多，并且可以直接执行 TypeScript 文件而不需要额外的编译步骤。渲染层则跟 Tauri 一样，使用系统 WebView：macOS 上用 WebKit，Windows 上用 Edge WebView2，Linux 上用 WebKitGTK。原生绑定层——也就是窗口管理、菜单、系统托盘这些 OS 级别的功能——用 Zig 来实现。Zig 是一门新兴的系统编程语言，比 C 更现代，比 Rust 的学习曲线更平缓，编译出来的二进制文件同样非常精简。
这个组合方式让 Electrobun 同时达到了几个目标：开发者全程写 TypeScript，不需要学 Rust 或 C++；打包出来的应用体积约 12MB，比 Electron 小 90% 以上；冷启动时间在 50ms 以内，而 Electron 通常要 1 到 2 秒。
架构设计里的几个有趣细节
Electrobun 在进程隔离这件事上做得比较彻底。主进程（Bun）和渲染进程（WebView）之间通过有类型约束的 RPC 来通信，而不是像 Electron 早期那样用一个宽松的 IPC 随便传消息。这种设计的好处是编译期就能发现类型错误，减少运行时的意外。两个进程之间通过命名管道传递消息，Zig 层负责在 Bun 和 WebView 之间做桥接和 DOM 定位。
Electrobun 还实现了一个叫做 OOPIF（Out-of-Process iframes）的功能，通过自定义的 <electrobun-webview> 标签来创建真正隔离的 iframe，每个 WebView 都运行在独立的进程里。这对于需要加载不受信任的第三方内容的场景来说非常实用，安全隔离做得比普通 iframe 要彻底得多。
更让我眼前一亮的是它的更新机制。Electrobun 内置了一套基于 bsdiff 算法的二进制差分更新系统，还加上了 SIMD 优化和 ZSTD 压缩。实际效果是：一个小改动的增量更新包可以小到 14KB，而 Electron 应用每次更新通常都要重新下载整个安装包（100MB+）。对于频繁迭代的产品来说，这个差距非常显著，也直接影响用户的更新意愿。
和 Electron、Tauri 的对比
如果要放在一个表格里直观比较，大概是这样的：Electron 的优势在于生态成熟、调试工具完善、API 覆盖全面，缺点是体积大、内存高、启动慢；Tauri 的优势在于体积小、安全模型严格，缺点是需要写 Rust，对 Web 开发者不友好；Electrobun 的优势在于全 TypeScript 开发体验、启动速度极快、体积控制得好，但目前生态还比较年轻，社区资源相对 Electron 少很多。
从开发体验角度来看，Electrobun 对有 Node.js 背景的开发者来说几乎没有任何迁移成本，毕竟 Bun 的 API 和 Node.js 高度兼容。你可以继续用 React、Vue 或者 SolidJS 写 UI，用 TypeScript 写主进程逻辑，工程工具链也是熟悉的那一套。这和 Tauri 形成了鲜明对比——Tauri 的设计虽然优雅，但你一旦需要做系统级的操作，就得切换到 Rust 的上下文。
平台支持方面，Electrobun 官方目前支持 macOS 14+、Windows 11+ 和 Ubuntu 22.04+，macOS 提供 ARM64 和 x64 两个架构。有一点需要注意，目前在 Linux 上，应用菜单功能还没有完全实现，这对某些应用来说可能是个限制。
上手体验
初始化一个 Electrobun 项目非常简单，一行命令就能搭好脚手架：
npx electrobun init
项目结构跟普通的前端项目差不多，src/main.ts 是主进程入口，src/renderer/ 放 UI 相关文件，electrobun.config.ts 是构建配置。整个开发流程和写一个普通 Web 应用没有太大区别，只是多了主进程这一层需要关注。
在主进程里，你可以用 Electrobun 提供的 API 来创建窗口、控制菜单、操作剪贴板、弹出原生对话框、管理系统托盘。这些 API 的设计风格和 Electron 比较接近，有 Electron 经验的人上手会很顺畅。跨进程调用通过类型安全的 RPC 来做，定义好接口之后，TypeScript 的类型系统会帮你检查调用是否正确，这个体验比 Electron 里用字符串事件名来做 IPC 要舒服得多。
目前框架的文档还在完善中，有些细节需要翻 GitHub 的示例才能搞清楚。不过考虑到它才 1.0，这也在预期之内。团队本身就在用 Electrobun 重写他们自己的产品 co(lab)，所以 dogfooding 做得比较扎实，遇到的问题应该也会比较快被发现和修复。
最后
Electrobun 现在处于一个很有意思的位置。它的技术选型很聪明：把 Bun 的运行时速度、系统 WebView 的轻量、Zig 的高效原生绑定组合在一起，同时把开发界面保持在 TypeScript 层，大幅降低了上手难度。对于独立开发者或者小团队来说，如果你想构建跨平台桌面应用，又不想被 Electron 的体积和性能拖累，也不想花时间学 Rust，Electrobun 是一个真正值得认真考虑的选项。
当然它目前的生态还比较早期，插件和社区资源肯定没法和 Electron 比，碰到边缘问题可能需要自己去翻源码。但我觉得这类框架的核心价值本来就不在于生态有多庞大，而在于它的架构设计是否正确、开发体验是否流畅。从这两点来看，Electrobun 给出的答案让我还挺满意的。如果你有新的桌面应用项目在规划中，不妨去 electrobun.dev 看看文档，试着跑一下示例，感受一下那个几乎感觉不到延迟的启动速度。
