Deno 2.9: 推出用於原生應用程式的 deno desktop

Deno 2.9 引入了 deno desktop，這是一個全新的指令，能將 Deno 專案（從單個 TypeScript 檔案到像 Next.js 這樣的全端框架）轉換為獨立且可重新分發的桌面端二進位檔。此工具將應用程式碼、Deno runtime 與網頁渲染引擎打包成單一的平台特定執行檔。

deno desktop 的核心能力

deno desktop 旨在透過提供高度整合的工具鏈來減少構建桌面應用程式的摩擦，該工具鏈可處理打包、渲染與更新。

開發者可以在兩種主要的渲染策略之間進行選擇，以平衡二進位檔大小與一致性：

OS WebView (預設): 使用作業系統的原生 webview 以保持較小的二進位檔大小。
Chromium (CEF): 打包 Chromium Embedded Framework (CEF) 以確保在 macOS、Windows 與 Linux 之間具有一致的渲染效果。

deno desktop 內建對熱門網頁框架的支持。它會自動偵測並配置以下框架：

Next.js, Astro, Fresh, Remix, Nuxt, SvelteKit, SolidStart, TanStack Start, 以及 Vite SSR。

在發佈模式下，它會執行生產伺服器；在開發期間，它支援 --hmr 旗標以進行熱模組替換，而無需修改原始網頁專案的程式碼。

與通常依賴基於 socket 的程序間通訊 (IPC) 的 Electron 或 Tauri 不同，deno desktop 使用程序內通道 (in-process channels) 在後端與 UI 之間進行通訊。雖然在跨越呼叫邊界時數值仍會進行編碼，但這種架構消除了跨程序往返的開銷。

單機構建: 開發者可以從單一機器編譯出 macOS、Windows 與 Linux 版本，因為後端會根據需求下載，而非在本地構建。
二進位檔差異更新 (Binary-Diff Auto-Updates): Runtime 包含一個使用 Deno.autoUpdate() 的內建更新系統。它利用 latest.json 清單與 bsdiff 補丁來輪詢、套用並自動回滾失敗的更新。

建立一個基礎的桌面應用程式僅需極少的設定。在 main.ts 檔案中一個簡單的 Deno.serve() 處理程序即可透過指令 deno desktop main.ts 轉換為二進位檔。

deno desktop 提供了一套完整的原生 API 與配置：

視窗管理: Deno.BrowserWindow 處理多個視窗的生命週期與事件。
原生 UI 元件: 支援應用程式與右鍵選單、系統匣圖示以及 macOS dock 整合。
作業系統整合: 提供 prompt()、alert() 與 confirm() 的原生彈出視窗，以及透過 Web Notification API 提供的原生 OS 通知。
開發者工具: 統一的 DevTools，可同時掛載到 Deno runtime 與 webview 上。

在宣布之後，開發者社群針對 deno desktop 的架構提出了幾項策略優勢與潛在疑慮。

某些使用者指出，deno desktop 透過使用原生 WebViews 來實現小型二進位檔，其架構與 Tauri 鏡像相似，但將業務邏輯從 Rust 替換為 TypeScript。

"對於 Tauri 的架構很熟悉，但你的業務邏輯是在 typescript 而不是 rust。"

其他人則認為，能夠直接執行真正的 TypeScript（無需剝離型別）讓 Deno 在與基於 Node 的替代方案競爭時具有優勢。

關於 Deno 的權限系統在編譯後的二進位檔情境下的問題也隨之被提出。目前，在編譯時授予的權限會被封裝進二進位檔中。

批評者指出，無論使用哪種 runtime，依賴網頁技術來構建桌面 UI 往往會導致應用程式無法遵循原生 OS 的設計模式。

"Electron 應用程式之所以受到許多抨擊，是因為它們除了 UI 工具包之外什麼都不是。它們在採用宿主 OS 的 UI 模式方面始終無法達到標準。"

關於基於 CEF 的應用程式二進位檔大小的討論仍在進行中。一項提議的 roadmap 項目涉及在應用程式之間共享 CEF runtime，以將每個應用程式的佔用空間從數百 MB 減少到幾個 MB。