Deno Desktop 正式登場：把整個 Web 專案打包成原生桌面 App

編按：本文綜合整理自 Deno 官方文件、Ryan Dahl（@rough__sea）官方公告、Hacker News 402 點熱門討論，以及 Deno Desktop 與 Electron / Tauri / Dioxus 的官方比較頁，並加入 Siami 編輯部觀點與分析。

Deno 團隊於 Deno 2.9 canary 版本中，正式推出 deno desktop 命令列工具。這是 Deno 從「JavaScript 執行環境」跨向「桌面應用程式開發框架」的重大一步。從一段 TypeScript 檔、一個 Next.js 專案，到整個 Fresh / Astro / SvelteKit 網站，都能直接 deno desktop main.ts 編譯成可散佈的原生二進位檔，內含 Deno runtime 與 WebView 渲染引擎。

Ryan Dahl 在 X 上親自公告：「這大概是醞釀一年以上的成果，下週隨 Deno 2.9 釋出」，並標註兩位主要貢獻者 @undefined_void 與 @crowlKats。HN 上這則消息在 4 小時內衝到 402 分、164 則留言，社群反應熱烈。

deno desktop 是什麼

Deno 官方文件寫得很直接：deno desktop 把一個 Deno 專案（從單一 TypeScript 檔到整個 Next.js App）打包成自帶 runtime 的桌面應用程式，產出物是一個可重新分發的二進位檔，每個平台一份，內含程式碼、Deno runtime 與 Web 渲染引擎。

要注意的是，這個功能目前還沒進入 stable。要嘗試的話需要執行 deno upgrade canary 安裝 canary 版，Deno 2.9 正式釋出後才會是穩定功能，命令、設定鍵與 TypeScript API 都還可能再變動。

為什麼 Deno 要做自己的桌面框架

官方文件開門見山：Web 技術是世界上最多人會的 UI 工具組。用 Web stack 做桌面 App（Electron、Tauri、Electrobun）享受了這個紅利，但每個方案都有自己的取捨要吞：

• 二進位檔肥大
• 平台支援不齊
• 沒有 JavaScript 生態
• 沒有內建更新機制
• 沒有框架整合

Deno Desktop 對這些取捨有明確的立場：

• 小體積預設，完整 Node 相容。預設使用作業系統自帶的 WebView（讓二進位檔保持精簡），但透過 Deno 的 Node 相容層，整個 npm 生態都還能用。需要三平台渲染完全一致時，可選擇打包內建 Chromium（CEF）的 backend。

• 框架自動偵測。直接指向 Next.js、Astro、Fresh、Remix、Nuxt、SvelteKit、SolidStart、TanStack Start 或 Vite SSR 專案就能跑：release 模式用 production server，開發模式加上 --hmr 就支援熱重載。完全不用改既有 Web 專案程式碼就能搬上桌面。

• 行程內綁定（in-process bindings），不用 IPC。後端與 UI 通訊走行程內 channel，不是 socket-based IPC。值在跨越呼叫邊界時還是會編碼，但 Deno 程式碼和 WebView 之間不會有跨行程的 round-trip。

• 從一台機器 cross-compile。同一台機器可以建出 macOS、Windows、Linux 三平台版本。後端是需要的時候下載，不是在本地編。

• 內建 binary-diff 自動更新。只發一個 latest.json manifest 加 bsdiff patch，runtime 會輪詢、套用、並在啟動失敗時自動回滾。

一個檔案就能開窗

文件示範的最簡範例：

// main.ts
Deno.serve(() => new Response("<h1>Hello, desktop</h1>", {
  headers: { "content-type": "text/html" },
}));

然後執行：

deno desktop main.ts

編譯出來的二進位檔會自動開一個視窗，指向 Deno.serve() 綁定的本地 HTTP server。執行 ./main（macOS / Linux）或 .\main.exe（Windows）就能直接開啟。Deno.serve() 會自動綁到 WebView 導向的位址，不用自己傳 port 或 hostname。

文件下方列出 Deno Desktop 目前支援的進階功能：

• Bindings：從 WebView 用 bindings.<name>() 呼叫 Deno 程式碼
• Menus：應用程式與右鍵選單
• Tray and dock：系統狀態圖示與 macOS dock
• Dialogs：prompt()、alert()、confirm() 做成原生彈窗
• Notifications：透過 Web Notification API 送原生 OS 通知
• Hot module replacement：框架與非框架 App 都支援 --hmr
• DevTools：統一 DevTools 同時附掛 Deno runtime 與 WebView
• Auto-update：Deno.autoUpdate()、manifest、bsdiff、回滾
• Error reporting：抓 uncaught exception 與 panic
• Distribution：cross-compile、輸出格式、安裝包

跟 Electron、Tauri、Dioxus 的關係

文件直接開了一個 Comparison 章節 跟這幾個專案對照。從 HN 留言與其他獨立分析整理，Deno Desktop 切入的定位是「想要 Electron 的便利 + 想要 Tauri 的精簡，且不需要 Rust」。

官方比較頁提到幾個重點差異：

HN 上 GeneralMaximus（貼文原作者）留言補充了一個關鍵點：Tauri 在 Linux 用 WebKitGTK，但 WebKitGTK 一直以來都有慢、不穩、且落後主線 WebKit 的問題。這問題嚴重到 Tauri 自己都在開發「改用 CEF 取代系統 WebView」的能力。Windows 與 macOS 上情況還好，因為 Edge 與 WebKit 本身就是 evergreen 版本，但如果你要支援很舊的 Windows 或 macOS，CEF 反而比對抗「五年前的 Safari」更實用。

fiatpandas 也強調：Deno Desktop 預設用系統 WebView，但可以選擇打包 CEF。Tauri 只支援系統 WebView。

為什麼這件事重要

Deno Desktop 對前端工程師的意義，不只是「又多一個桌面框架」。它直接處理三個一直以來 desktop framework 的痛點：

第一，框架自動偵測真正實用。Electron 跟 Tauri 都要求開發者自己寫設定檔、把 Next.js / Vite 專案包進來。Deno 走「偵測到就自動跑」，等於把 Web 開發者從桌面打包的繁瑣設定解放出來。

第二，--hmr 熱重載是真的熱。HN 上 @neobrain 比較了 Dioxus 與 React 的 live-reload：「Dioxus 的 live-reload 延遲低於一秒，雖然不是 game changer 但在視覺細節迭代時確實好用」。Deno Desktop 把這套體驗搬到 TypeScript 生態。

第三，權限系統的延伸可能性。@sheept 在 HN 點出一個關鍵：Deno 最有名的就是「預設沙盒、執行時明確給權限」這套。CLI 文件說「編譯時授予的權限會被烤進二進位檔」，但官方自己也在文件承認：「Deno Desktop 目前還沒做 runtime permissions for desktop apps」，也就是說現在編譯完，權限是固定的，不能像 deno run --allow-net=example.com 那樣在執行時動態授權。這是目前最大的限制，也是 Deno 社群最期待的功能之一。

對台灣與中文圈的工程師，Deno Desktop 的吸引力在於：你不需要學 Rust 也能打包桌面 App。Rust 是 Tauri 與 Dioxus 的入場券，但 TypeScript / JavaScript 是台灣 Web 工程師最熟的語言。Deno Desktop 直接把這個落差填平。

數據解讀 / 質疑

從 HN 留言與其他比較文，Deno Desktop 確實有幾個值得質疑的點：

二進位檔大小：Deno Desktop 的比較頁說比 Electron 小，但不是每個情況都小。HN 留言 @franz899 引用官方比較頁：「大約 40 MB vs 150 MB」——只比 Electron 小 73%，但 Tauri 通常能壓到 10 MB 以下。如果你的目標是「極小安裝包」，Tauri 仍然勝出。

效能：Deno Desktop 預設用系統 WebView，理論上跟 Tauri 一樣快，但實測目前還沒有第三方 benchmark 跑出來。Electron 的「啟動慢、RAM 肥」是社群長期詬病，Deno Desktop 能不能擺脫這個標籤還要時間驗證。

Stable 還沒到：Deno 2.9 canary 雖然 6/22 已能下載，但官方說「命令、設定鍵、TypeScript API 都還可能再變動」。現在投入正式產品風險偏高，建議等到 Deno 2.9 stable 釋出。

社群問題：@HackerThemAll 在 HN 回報：「D:\source\DenoTest>deno desktop main.ts → error: Module not found」。也就是說 canary 版本還有一些基本 case 沒處理好，建議先在 canary 等一兩週再投入。

@matharmin 的犀利提問：「你說 Unlike Deno Desktop? Deno Desktop 明確就是依賴瀏覽器引擎啊。」——這呼應 @lwansbrough 提到的 JumpJet，一個 WASM-based 跨平台遊戲框架，反其道而行：不用瀏覽器引擎，靠 WASM 直接打包成 Windows、macOS、Linux、Android、iOS、Web 二進位。如果你的 App 不需要 Web 渲染，這條路可能更乾淨。

Siami 觀點

把這件事放回 Deno 整體戰略來看，Deno Desktop 是 Ryan Dahl 在 2018 年 Deno 1.0 願景的延伸：建立一個完全替代 Node.js 的現代化執行環境。但 Deno 在 2025 年被社群質疑「在 Node 相容上花太多資源但沒看到成果」（HN 過往文章「Deno’s Decline」有 208 分），於是 Deno 2.0（2024-10）轉向擁抱 Node 相容、吃下 npm 生態。

Deno Desktop 是這個策略的下一步：把「Deno 也能跑桌面」的拼圖補上，等於告訴前端工程師「你不必離開 TypeScript / Node 生態就能做 desktop app」。

競爭對手方面，Tauri 已經是 Rust-based desktop 的事實標準，Electron 仍然是 Node-based desktop 的霸主。Deno Desktop 要搶的不是這兩塊，而是「Web 工程師已經會 TypeScript，不想學 Rust，又嫌 Electron 太肥」這個利基市場。從 HN 402 分、164 則留言的反應看，Deno 確實打中了這個族群。

但要注意，Deno Desktop 目前是社群話題度高、實戰參考少的階段。HN 上 @Culonavirus 提醒：「Electron 不是單純 UI toolkit，整個 Chromium 的工具鏈才是它的價值。Video playback、transcoding、webcodecs… 這些 Web API 在桌面 App 場景是『幾十小時做完 vs 幾十天做完』的差距。」Deno Desktop 如果未來能完整內建 Chromium（CEF 已開了這條路），才有機會正面對決 Electron。

社群回應

@neobrain：Dioxus 把程式邏輯編譯成原生碼，再用自家 HTML renderer（Blitz）取代整個瀏覽器，所以比 Electron 輕量且更快。Live-reload 也比 React 框架快很多，視覺細節迭代時很有感。

@Culonavirus：Electron 之所以被選，不是因為 UI 漂亮，而是因為整個 Chromium 的工具鏈都在裡面。如果你做過 video 相關應用就會知道，現代瀏覽器的 video playback / transcoding / webcodecs 在跨平台桌面 App 是「幾十小時做完 vs 幾十天做完」的差距。

@sheept：我想知道這跟 Deno 的權限系統怎麼整合。Deno 的強項是預設沙盒、明確授權，但 CLI 文件寫「編譯時授權烤進二進位檔」，執行時使用者沒辦法知道或決定要給哪些權限。希望未來能做到桌面 App 也有 runtime permission prompt。

@GeneralMaximus（貼文原作者）：這是很多 App 真正需要的功能。Tauri 在 Linux 用 WebKitGTK，但它一直很慢、不穩、且落後主線 WebKit，嚴重到 Tauri 自己都在開發改用 CEF 的能力。

@vinkelhake：「Web UI slop」這種說法我看了很多年。所謂的「原生 UI 框架」其實狀態也不好——如果桌面 App 都被 Web framework 攻佔了，問題不是罵 Web framework，而是原生 framework 自己為什麼沒人做。

@kiicia：Chromium 現在基本上是作業系統了，只差核心跟開機能力。每個 App 都打包一份 Chromium 來渲染只有一個文字輸入框的 Web 表單，這不合理。應該用 PWA 取代。

@leleat：Deno Desktop 比較頁說「共用 CEF runtime」是 roadmap：每個 App 不再各自打包 CEF，共用一份能把二進位壓到幾 MB。但這要怎麼處理不同 App 對 CEF 版本的相容性？會不會又回到 Electron 那種「每個 App 綁一個瀏覽器」？

@resonious：現在只有 macOS 還算有「一致的外觀」。其他作業系統「原生長相」到底是什麼，連定義都難講。多數 App 也都有自己的品牌風格要呈現，所以「App 應該長得像原生」早就不該是拒絕 Electron 的理由。