Deno Desktop

# Deno Desktop — Ankur Sethi 来源：https://ankursethi.com/blog/deno-desktop/ 2026年6月24日 印度标准时间晚上7:43 引用自 Deno 文档中*Desktop apps*部分（https://docs.deno.com/runtime/desktop/）： > `deno desktop` 可将 Deno 项目（从单个 TypeScript 文件到 Next.js 应用）转换为自包含的桌面应用程序。输出是一个可重新分发的二进制文件，它将你的代码、Deno 运行时和一个网页渲染引擎打包成每个平台一个包。 很高兴看到另一次解决 Electron 应用最大问题的尝试（其他值得注意的尝试包括 Tauri (https://tauri.app/)、Electrobun (https://blackboard.sh/electrobun/docs/) 和 Neutralinojs (https://neutralino.js.org/)）。根据文档，Deno Desktop 目前仅在 Deno 的 `canary` 频道可用。所以我显然安装了它（版本 `2.8.3+893d85b`），并尝试运行了一个 Hello World 示例应用（https://docs.deno.com/runtime/desktop/#hello%2C-desktop）。 首次运行时，Deno 花了几分钟下载了 `laufey-cef-aarch64-apple-darwin.tar.gz`，然后将示例打包成一个大小为 308.8MB 的应用包。我对这个下载很好奇。快速用 Kagi 搜索后，我找到了一个名为 laufey (https://littledivy.github.io/laufey/) 的 Rust/C 库的主页，它似乎是 Deno Desktop 的底层技术。运行应用包会弹出一个窗口，如下图所示： Deno Desktop CEF (https://media.ankursethi.com/original_images/CleanShot_2026-06-22_at_19.03.492x.png) 这显然还在开发中。如果有 Deno 的员工读到这篇文章，这里是我注意到的一些 bug： - 应用窗口默认有深色背景，尽管演示应用没有任何样式。浏览器默认不会使用深色背景，除非你明确通过 `` 选择开启。即使如此，开启深色模式会反转*所有*默认颜色，而不仅仅是页面背景。这里有点问题。 - 运行应用包触发了 macOS 权限对话框，分别是 `laufey Helper (Alerts)` 和 `hello-deno-desktop`，两者都在请求通知权限。演示应用没有使用通知 API（甚至不包含任何 JavaScript），因此看到两个权限对话框感觉有些激进。 - 按下 `Cmd + Q` 并没有退出应用。 - 应用总是打开在屏幕的左上角。 Deno 默认使用 Chromium 作为 webview（通过 Chromium Embedded Framework (https://chromiumembedded.github.io/cef/)）。但你也可以改用系统 webview： ``` $ deno desktop --backend webview main.ts ``` 当我运行那个命令时，它下载了 `laufey-webview-aarch64-apple-darwin.tar.gz`，并生成了一个更精简的应用包，只有 68.5MB。窗口看起来是这样的： Deno Desktop 原生 webview (https://media.ankursethi.com/original_images/CleanShot_2026-06-22_at_19.08.542x.png) 这个版本的应用没有出现我在 CEF 版本中注意到的任何 bug，只是没有标题。 Deno Desktop 还有一个 `raw` 后端，它完全跳过捆绑 webview。我没有尝试，但文档是这样说的： > **没有 Web 引擎。** 提供窗口管理、输入事件、剪贴板和原生 API 接口，但没有 webview，没有 `Deno.serve()` (https://docs.deno.com/api/deno/~/Deno.serve) 的自动绑定，也没有 `bindings.()` 代理。适用于绘制自己的 UI（WebGPU、Skia、自定义渲染）的应用，或作为非 Web 桌面程序的基础。`raw` 后端通过 `deno.json` 中的 `desktop.backend` 字段选择；`--backend` 标志仅接受 `cef` 和 `webview`。 Deno Desktop 与其竞争对手的一个主要区别在于，它在 webview 中运行的代码与 Deno 运行时中运行的代码之间的通信方式： > 绑定不是 IPC。Deno 运行时和渲染后端作为线程/进程运行在相同的地址空间（CEF）或协调进程组（WebView）内。调用经过进程内通道，后端从其运行循环中调度它们。这避免了基于 socket 的 IPC 框架（Electron 的 ipcMain / ipcRenderer、Tauri 的 invoke）所强加的跨进程往返。参数和结果在跨越 realm 边界时仍会被编码，但传输是进程内的：没有 socket，没有跨进程调度。实际上：绑定足够快，对于典型的应用负载，你无需担心调用频率。 文档对如何实现这一点描述得较轻。我很想了解更多。 有一个内置的自动更新机制，包括在更新失败时回滚： > Deno.autoUpdate() 轮询发布服务器以获取新版本，下载二进制差异补丁，将其应用于运行时动态库，并将结果暂存以供下次启动。如果下次启动失败，运行时会自动回滚到之前的版本。更新以小的 bsdiff 补丁形式发布，而不是完整的二进制下载，回滚功能内置于启动器中。 比较页面在“`deno desktop` 尚未具备的功能”部分下有这个要点： > **跨应用共享 CEF 运行时。** 每个应用目前都捆绑自己的 CEF 副本。托管共享运行时可以将二进制大小降至每个应用几 MB。已在路线图中。 这是否意味着我电脑上的所有 Deno 应用可能共享单个 CEF 运行时？如果是，那将节省大量磁盘空间。但尚不清楚开发者是否打算在未来的版本中提供此功能，还是只是一个可能或不会实现的心愿单项目。 当然，Deno Desktop 仍在大力开发中。一些重要功能仍然缺失（平台原生文件对话框），也不清楚其他功能是否在路线图上（移动支持）。我相信许多缺失的功能最终会进入正式版本，我们将在发布公告中更清楚地了解未来计划。我对任何旨在取代 Electron 的事物都有个人兴趣，因此我将密切关注 Deno 2.9。