Electron 写了三年，我一直觉得这套桌面胶水代码不该存在——Deno 2.9 终于换了个思路

前端团队想把一个 Web 项目做成桌面应用，Electron 是最常见的选择。但项目跑起来之后你会发现，仓库里多了一套东西：main process、preload 脚本、IPC 通道、打包配置、代码签名、自动更新链路。这不是一次性初始化就完了——每次给应用加一个本地能力调用，都要在 renderer、preload、main 三层之间重新走一遍注册、暴露、调用的流程。这套东西占着仓库的位置，维护着维护着就成了负担。

Deno 2.9（6 月 25 日正式发布）想换掉这个思路。它没有再造一个浏览器壳，而是把桌面应用当成 Deno 运行时的一个输出目标，而不是一个独立工程。

原来三层，现在两层

Electron 的调用链是这样的：renderer → preload API → ipcMain → main process → 文件系统。preload 负责暴露接口，ipcMain 负责消息路由，main process 负责系统调用，三层靠 IPC 样板串联。

Deno Desktop 的调用链：WebView → bindings → Deno runtime → 文件系统。bindings 直接把 Deno 的能力暴露给 WebView，跳掉了 preload 和 IPC 这一整层。

用一个读取配置文件的场景举例：

// Electron：renderer 调用
const data = await window.electronAPI.readSettings();
// 背后走了：preload暴露 → ipcMain路由 → main process读文件

// Deno Desktop：直接调用
const data = await readSettings();
// 背后走了：bindings → Deno runtime → 文件系统

bindings 省掉的不是某几行代码，而是 preload 和 IPC 这一层样板的结构性存在。当然 bindings 仍然是能力入口——任意路径文件操作仍然要换成语义化接口，在 Deno 侧做目录白名单和数据校验，安全模型并没有消失，只是从「维护三层结构」变成了「设计好语义化接口」。

三种方案的实在差距

数字是死的，决策是活的。包体差几十 MB 在多数场景下不是第一优先级，但桌面胶水代码的维护成本在项目迭代足够多之后，常常超过首包体积差异。胶水代码的成本不取决于选了多大的包，而取决于所选方案到底要不要这套胶水代码。

适用边界，说清楚

Deno Desktop 现在不适合替换成熟的 Electron 项目。需要代码签名、安装包和完整自动更新链路的场景，Electron 仍然最稳。对包体极度敏感或需要移动端支持的项目，Tauri 是更现实的选择。

Deno Desktop 的起步场景是内部工具的技术预研。本地配置面板、日志查看器、文件处理工具——这些场景对签名和更新链路依赖低，桌面胶水代码却一点不少，而团队可能已经在用 Deno/TypeScript 了。

验证成本足够低，两条命令：

deno upgrade canary
deno desktop .

验证三件事：项目结构能否识别、窗口能否正常打开、开发热更新是否保留。跑通了，你得到的不是一个新工程，而是一个已有的 Deno/TypeScript 项目多了一个桌面输出目标。

Deno 2.9 同时改善了启动时间、内存占用和 HTTP 吞吐量。如果你的团队已经在用 Deno 全栈，这套桌面方案可以开始评估了——不是现在就替换 Electron，而是在下一个内部工具立项时，多一个维护成本更低的选择。