面向 TypeScript 开发者的 Electron 替代方案
Electron 让 Web 开发者也能轻松制作桌面应用，而它在体积和内存上 的代价，也让“Electron alternative”成了一个长盛不衰 的搜索词。如果 TypeScript 是你的语言，2026 年有四条现实的路 径：留在 Electron、转向 Tauri、用 Bun 构建内嵌运行时的二进制 文件，或者用 Perry 编译为原生代码。它们做出的取舍截然不同。
四种方案
Electron——基准方案
每个应用都打包了 Chromium 和 Node.js。好处是十多年的生产 环境成熟度，以及一套你的团队已经熟悉的 UI 技术栈 （HTML/CSS/JS）——VS Code、Slack 和 Discord 都构建在它之 上。坏处是基础成本：hello-world 安装包约为 80–150 MB，多 个 Chromium 进程，空闲时占用数百 MB 内存。仅限桌面端。 完整的 Perry 对比 Electron。
Tauri——在系统 webview 中运行 Web UI，后端为 Rust
Tauri 保留了 Web 前端，但去掉了打包的 Chromium：UI 在操作 系统自带的 webview（WKWebView、WebView2、WebKitGTK）中渲 染，因此安装包体积落在个位数 MB 量级。它稳定、文档完善， 且 Tauri 2 增加了对 iOS/Android 的支持。代价是：后端是 Rust，而不是 TypeScript——UI 之外的应用逻辑意味着要写 Rust 并跨越一个 IPC 桥——而且由于每个操作系统自带的 webview 不 同，渲染表现在各平台之间会有细微差异。 完整的 Perry 对比 Tauri。
Bun——单文件二进制，没有 GUI 层
搜索“bun electron”的人通常是想要 Electron 的便 利，却不想承担它的体积。 bun build --compile 通过把 Bun 运行时和你打包好的 TypeScript 一起内嵌，产出单 个可执行文件——非常适合 CLI 和服务端场景，由于它本身就是 运行时，因此拥有完整的 npm 兼容性。但这个二进制文件大约在 60 MB（macOS arm64）到 100+ MB（Linux/Windows）之间，代码 依然以 JIT 方式执行，而且 Bun 没有 UI 框架——桌面应用仍然 需要在其上叠加 Electron、Tauri 或某个 webview 库。 完整的 Perry 对比 Bun。
Perry——将 TypeScript 编译为原生组件
Perry 把 TypeScript 提前编译为机器码，并通过真正的平台组 件——AppKit、UIKit、GTK4、Win32，以及通过 JNI 实现的 Android——渲染 UI，完全没有 webview，也没有 IPC 桥。UI 和 逻辑用同一种语言，hello world 约 330 KB，典型二进制约 2–5 MB，启动时间约 1 毫秒，十个目标平台涵盖移动端、手表 和 TV。坦诚的提醒：Perry 是 Pre-1.0，它的 UI API 是自成一 体的（声明式，SwiftUI 风格——而非 HTML/CSS），生态相比 Electron 还很年轻。
并排对比
| Perry | Electron | Tauri | Bun (--compile) | |
|---|---|---|---|---|
| 语言 | 全程 TypeScript | JS/TS + HTML/CSS | JS/TS 前端，Rust 后端 | TypeScript |
| UI 方案 | 原生平台组件 | 内置 Chromium | 系统 webview | 无（CLI/服务端） |
| Hello-world 大小 | ~330 KB | ~80–150 MB | ~3–10 MB | 按平台约 60–116 MB |
| 执行方式 | AOT 机器码 | JIT（V8） | JIT（webview JS 引擎）+ 原生 Rust | JIT（JavaScriptCore） |
| 空闲时内存占用 | 数十 MB（单一原生进程） | 数百 MB（多进程 Chromium） | 低于 Electron（系统 webview） | 运行时的典型水平 |
| 移动 / 手表 / TV | iOS, iPadOS, Android, watchOS, tvOS | 不支持 | iOS, Android (Tauri 2) | 不支持 |
| 成熟度 | Pre-1.0 | 生产环境十余年 | 稳定（1.x/2.x） | 稳定 |
React Native 或 Flutter 呢？
它们在每个讨论 Electron 的话题里都会出现，但它们回答的是不同 的问题。React Native 是移动优先的：你的 JavaScript 运行在 Hermes 引擎中，并通过一座桥驱动原生视图，桌面端支持仅存在于 独立的社区/微软分支中——它并不是 Electron 的直接替代品（Perry 对比 React Native）。Flutter 覆盖桌面和移动端，但意味着要放弃 TypeScript 转投 Dart，而且它是自己绘制组件，而不是使用平台自带的组件。如果留 在 TypeScript 是硬性约束，那么现实可行的桌面端候选仍然是上述 四个选项。
应该选哪一个？
留在 Web 技术栈
如果你的 UI 已经用 React/Vue/Svelte 构建好了，而且今天就 需要经过实战检验的桌面端分发方案，Electron 仍然是风险最 低的选择——代价是体积和内存。如果这个代价让你在意，并且你 愿意用 Rust 写后端，Tauri 能以极小的体积代价给你大部分 Web 技术栈的体验。
抛开 webview
如果你真正想要的是“输入 TypeScript，输出原生应 用”——一种语言、真正的平台组件、小体积二进制文件， 以及用同一份代码覆盖移动端/手表/TV——这正是 Perry 存在的 意义，代价是 Pre-1.0 的成熟度。而如果你只需要一个零兼容 性风险的单文件 CLI 或服务端程序，Bun 的 --compile 就是务 实之选。