不用Electron也能做桌面应用了！Deno 2.9一个命令打包前端代码

VSCode、Slack、Figma、Claude——这些你每天在用的桌面应用，背后用的都是同一套技术：Electron。用HTML、CSS、JavaScript写前端，套一个Chromium的壳，就能跑在Windows、macOS、Linux上。

但Electron有个让人头疼的毛病：太臃肿了。一个Hello World应用轻松上百MB，因为每装一个Electron应用，等于在你的硬盘里塞了一个完整的Chromium浏览器。内存占用高，启动慢，用户吐槽”这不就是个套壳网页吗”——但没得选，因为之前没有同样好用的替代方案。

2026年7月，Deno 2.9带着一个叫deno desktop的新命令来了。它想做的事情很简单：用你熟悉的React、Vue、Next.js代码，一条命令打包成桌面应用，不带Electron玩。

Electron到底为什么又大又慢？

在聊Deno怎么做之前，先搞清楚Electron的结构。

Electron本质上是一个双层架构：底层是Chromium浏览器，负责渲染网页内容；上层是Node.js运行时，负责访问文件系统、系统通知、进程管理等操作系统能力。你的前端代码跑在Chromium里，通过Electron提供的IPC通信机制和Node.js对话。

这套架构好用，但代价是每一层都很重。Chromium本身就是一个完整的浏览器引擎，Node.js有自己独立的V8实例。两者加起来，基础包体积起步就是150MB往上，内存常驻轻松超过200MB。对于配置低一点的老电脑，多开几个Electron应用就直接卡死。

后续出现了一些轻量化尝试，比如Tauri用Rust替换Node.js层、用电系统自带WebView替换Chromium，包体积可以做到几MB。但Tauri需要开发者学Rust——对纯前端来说门槛不低。

Deno的做法：从根源上简化

Deno 2.9的思路比Tauri更直接：它本来就是JavaScript/TypeScript运行时，不需要再搬一个Node.js。渲染方面，它默认使用操作系统自带的内置浏览器引擎：

• Windows 用 WebView2
• macOS 用 WebKit
• Linux 可选 WebKit 或 Chromium（通过CEF）

这意味着你打包出来的应用，不需要附带一个完整的Chromium——操作系统已经帮你准备好了渲染引擎。一个基础桌面应用的包体积从Electron的150MB起步，直接压到几MB。

更关键的是，Deno能自动检测你项目里用的前端框架——不管是React、Vue、Next.js还是Nuxt，它都能识别并自动构建打包。不需要写额外的适配器，不需要改项目结构，零配置。

构建完成后，一行命令搞定跨平台：

deno desktop --target windows,macos,linux

从一台机器上就能交叉编译出Windows x86_64、Linux x86_64/arm64、macOS arm64/Intel五个平台的安装包。

但别急着替换生产项目

说清楚边界：deno desktop目前是Deno 2.9的实验性功能，不建议直接用于生产环境。

Electron虽然重，但它有十年的生态积累——electron-builder做安装包分发、electron-updater做自动更新、成熟的系统托盘和全局快捷键API，这些是Deno短期内补不上的。Tauri也已经在移动端（iOS/Android）上跑通了，Deno目前只支持桌面。

适合尝鲜的场景：原型工具、个人效率工具、内部管理系统。你想用前端技术栈快速做出一个桌面小工具，不想学Electron也不想学Rust，Deno desktop是目前最简单的选择。

这件事更大的意义

Deno desktop不是第一个想”干掉Electron”的项目，但它的思路值得关注：让前端技术栈的边界从浏览器扩展到桌面，不需要换语言、不需要学新框架。

三年前，前端开发者几乎只有Electron一条路做桌面应用。现在，Tauri、Electrobun、Deno desktop三路并进——各有取舍，但共同指向一个趋势：用前端代码做桌面应用这件事，正在变得跟写一个网页一样简单。

（本文参考来源：Deno 2.9官方发布公告、掘金前端技术社区2026年7月综合报道、Electron官方文档。）