編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

近日，Hacker News 上一篇名為《Deno’s Decline》（Deno 衰落）的文章引發了不少開發者的關注。

Deno 是一個現代 JavaScript 和 TypeScript 運行時，由 Node.js 的共同作者 Ryan Dahl 于 2018 年發起。這個項目的初衷是糾正他在設計 Node.js 時所留下的一些“遺憾”，例如模塊系統、安全模型和開發體驗等。憑借開箱即用、原生支持 TypeScript、更加注重安全性以及對現代 Web 標準的支持，Deno 一度在技術圈收獲了不少好評。

不過在這篇文章中，曾是 Deno 堅定支持者的技術人 David Bushell 直言，Deno 正在走下坡路。其批評了 Deno Land Inc. 推出的商業產品 Deno Deploy。該平臺號稱具備“全球范圍的邊緣計算能力”，可以將 JavaScript 應用的服務器端邏輯部署在離用戶更近的地理位置，從而實現低延遲和高性能——但 Bushell 認為，實際表現遠不如宣傳。

他指出自己在 2023 到 2024 年間親自試用了 Deno Deploy，整體體驗非常不理想。2024 年初，Deno Deploy 的部署節點從最初的 35 個銳減至 12 個；到了年底進一步縮減為 7 個，到 2025 年只剩下 6 個。比如首爾的節點被遷移至東京，響應時間從 8ms 飆升到 42ms，所謂“全球規模”幾乎名存實亡。

Bushell 還提到，除了 Deploy，Deno 的其他核心項目也都陷入停滯或乏力的狀態：

• Fresh 框架：自 2024 年 10 月以來沒有新版本發布，開發節奏明顯放緩；

• Deno KV：最后一個正式版本停留在 2023 年底，后續幾個版本只打了 tag 并未發布，官網和博客也沒有進一步動態；

• JSR（JavaScript Registry）：被他諷刺為 “NPM at home”，意指并未解決 NPM 存在的根本問題；

• Deno 運行時本身：更新內容大多是圍繞 Node.js 兼容性修修補補，缺乏真正的創新。他還指出 SQLite 支持其實是受 Node 推進所迫才補齊的。他甚至調侃 Deno 2.2 的“主打功能”居然是 telemetry（遙測），從側面反映出項目方向上的迷失。

Bushell 批評 Deno 背離了“修復 Node 生態”的初衷，早已不再是那個推動 JavaScript 根本性變革的項目，如今只是不斷追趕 Node 的步伐。他坦言自己曾對 Deno 寄予厚望，如今卻感到被“套牢”甚至“被割韭菜”，并自嘲是個“JavaScript 傻瓜”，但依然對新興競爭者 Bun 抱有期待，準備繼續跳進下一個“VC 支持的小丑車”。

隨著這篇文章引發廣泛討論，Deno 之父 Ryan Dahl 也做出了回應，發文澄清稱《關于 Deno 已死的報道被嚴重夸大了》。以下是他回應的全文內容：

最近有一些關于 Deno 的批評，涉及 Deploy、KV、Fresh 這些項目，甚至質疑我們整體的進展。你可能也在網上看到過這些聲音，它們在一些常見的社區傳播開來，吸引了不少關注。

有些批評確實有道理。說實話，我們在溝通上確實做得不夠，沒能及時、清晰地向大家說明我們正在做什么，未來的方向是什么。這導致了一些不安和疑問，這是我們需要承擔的責任。

但也有一些聲音并不準確，甚至帶有猜測成分。我們寫這篇文章，就是想把事情說清楚。這是一份近況更新，講講我們目前的發展、過程中的一些收獲，以及接下來要做的事。有些人擔心 Deno 已經走下坡路甚至快要“消失”，但這種說法完全不符合事實。

自去年 10 月發布 Deno 2 以來（其實才過去半年多！），我們的月活躍用戶數量已經翻了一倍。Deno 2 引入了對 Node 的強大兼容性，這打破了過去的一個主要障礙，讓很多實際場景都能順利使用 Deno。整個平臺變得更快、更簡單、功能更強大。如今，Deno 的使用范圍更廣，用戶也更加“認真”地在使用它。

Deno Deploy

我們最近聽到最多的問題之一，是關于 Deno Deploy 的，特別是有人質疑為何可用區域數量減少了。我們理解這種“收縮”的表面看起來可能會引發擔憂，但其實并不是外界猜測的那樣出了什么問題。

真實情況是：大多數應用根本不需要在全球每個角落都運行。它們更需要的是：響應足夠快、靠近數據源、調試方便，并能符合本地的合規要求。我們現在就是在圍繞這些核心需求做優化。

Deno Deploy 是我們在 2021 年上線的，目的是探索一種全新的無服務器 JavaScript 模式。最初支持 25 個區域，后來擴展到 35 個，現在減少到了 6 個。

是的，區域數量的縮減確實有成本方面的考慮，但更關鍵的是使用情況。

我們發現，開發者并不是在部署那種簡單的無狀態函數，而是在構建完整的全棧應用——這些應用通常需要訪問數據庫，而數據庫往往只部署在一個區域。結果就是，大多數區域幾乎沒人用。更糟糕的是，一旦流量突然上漲，那些平時“閑置”的區域反而最容易被打滿，導致響應變慢。后來我們發現，直接把請求路由到一個稍遠但運行良好的區域，反而比就近啟動一個“冷區域”還更快。

我們當初追求的是一種“邊緣計算”的理想狀態，但那其實并不符合大家實際的使用方式。對于這點，我們之前沒說清楚，這是我們的問題。

目前，Deno Deploy 正在大幅迭代開發。新版還沒正式上線，但已經非常接近了。你可以在這里（https://dash.deno.com/account）申請搶先體驗。

未來的 Deploy 不再只是一個函數托管平臺，而會發展成一個完整的應用托管平臺。它將支持子進程、后臺任務、OpenTelemetry、構建流水線、緩存，甚至支持自托管區域。像 Next.js、SvelteKit，還有我們自己的 Fresh 等全棧框架都能在上面運行。

很快，你就可以將應用固定在某個特定區域運行，或者部署在你自己的云環境中。這是許多用戶反復向我們提的需求——為了更好的控制力、合規性和性能。更多更新，敬請期待。

KV

Deno KV 是我們推出的一款“零配置”的全局一致性鍵值存儲，API 簡單，還支持實時功能。對于會話數據、功能開關、在線協作等場景來說，KV 表現非常出色。開發者喜歡它，就是因為它簡單、開箱即用，而且在全球范圍內都能很好地工作。

但我們也很清楚，它并不是萬能的。KV 不是通用型數據庫，也不能取代大多數應用中需要的關系型系統。為了滿足更廣泛的狀態管理需求，我們現在也在推進幾項新計劃：

• 首先，我們正在努力讓傳統的關系型數據庫（比如 PostgreSQL）在 Deno Deploy 中更容易使用、更加無縫集成。

• 其次，我們認為 Deno KV 在“計算與狀態的綁定”上做得還不夠。受到 Cloudflare Durable Objects 這類系統的啟發，我們正在開發一個新項目，目標是實現更緊密的綁定方式——也就是說，把狀態直接和計算邏輯關聯起來。

基于這些新的方向，Deno KV 會繼續保持 beta 狀態。我們會繼續修復關鍵 bug 和安全問題，但它不會成為 Deno 里“統一解決狀態管理”的那種核心方案。隨著我們在狀態管理方向上推出更多新工具，我們也可能對 Deno KV 做出較大的調整或改動。

這些新項目很快就會有更多消息，我們也非常期待跟大家分享進展。

Fresh

Fresh 依然活躍，狀態很好——我們公司自己所有的應用和網站，都是用 Fresh 構建的。我們知道很多人都在期待 Fresh 2 的到來，也理解有些用戶因為久等而感到有些失望。我們聽到了大家的聲音。其實我們本可以更早發布一個版本，但我們更希望把基礎打扎實，不想為了博眼球而犧牲質量。Fresh 是我們內部項目的“核心依賴”，所以它必須足夠可靠、足夠優秀。

正式版將在今年晚些時候發布。

Deno，不只是一個運行時

Deno 已經不只是一個 JavaScript 運行時了，它現在是一個完整的平臺，用來構建和運行 JavaScript 應用。它內置了：

• 原生支持 TypeScript 和 JSX

• 細粒度的權限控制和沙箱機制，確保運行安全

• 完整的語言服務器協議（LSP），配套 VS Code 插件，以及 deno check 提供類型檢查

• Jupyter Notebook 集成，支持 TypeScript 類型檢查

• deno compile 可以直接打包成可執行文件

• 對 Node.js/npm 的強大兼容性，包括 workspace 支持

• 一流的可觀測性，內建 OpenTelemetry，開箱即用的結構化追蹤（這是基礎設施，而不是事后補丁）

• deno fmt 自動格式化 JavaScript、TypeScript，甚至可以格式化模板字符串里的 CSS 和 SQL

• 完全基于 ES Modules 和 Web 標準構建

• 全球部署能力（通過 Deno Deploy）

• 包發布系統 JSR，擁有開放治理機制、不斷擴展的標準庫，以及出色的 workspace 支持

用 Deno，你可以用一套工具鏈完成編寫、運行、測試、部署和監控。我們不斷在做的是：減少命令參數，更好的默認行為，減少工具間的割裂。現在這些模塊協同工作的效果，比以往任何時候都要好。

我們并不是在追求功能和其他運行時一一對標，而是在構建一個統一、有機的系統。我們真正想做的是：從根本上改善 JavaScript 的開發體驗。如果我們有什么“錯”，那是因為我們走得太遠、目標太大。但我相信，沒有人會否認 Deno 是在為這個世界上默認的編程語言創造一個更好的未來。

我們為什么在做這件事？

腳本語言，天然就是解決很多業務場景最合適的終點形態，尤其是那些“工程時間”才是瓶頸的問題。

Ruby、Python、Lua、Perl、JavaScript 都走的是這條路。而 JavaScript 是唯一一個真正普及到了每一臺設備上的腳本語言，它有標準組織、有跨巨頭的獨立實現，還有龐大而活躍的生態。我們相信，有未來的腳本語言，就是 JavaScript（以及 TypeScript）。它值得擁有一個完整的平臺，而不是一堆臨時拼湊的工具。我們想提供的是一個“自帶電池”的一體化系統。

就像 JavaScript 給你內建了垃圾回收和數組，Deno 同樣開箱即用地提供了權限系統、Web 服務器、可觀測性、代碼檢查和類型安全。這些功能不需要你去拼接各種第三方工具——Deno 本身就是那個粘合劑。

展望未來

我們不是要結束，而是在加速。

我們會持續打磨性能、兼容性和平臺體驗。JSR 正在逐步成熟，我們也成立了一個開放治理委員會，正在推動將 JSR 過渡為一個真正獨立、由社區驅動的基金會。

我們在 TC39 和 WinterTC（原 WinterCG）中的參與也在繼續。同時，我們也在積極應對 Oracle 誤導性的 JavaScript 商標使用行為。這些都是我們為了推動 JavaScript 生態發展所做的一部分努力。

基于我們在 Deploy 和 KV 中積累的經驗，我們還在開發一些全新的產品（還未發布），目標是讓構建“持久化、分布式應用”變得更簡單。這些產品很快就會有更多消息。

我們知道，之前的沉默可能帶來了一些不安感。接下來我們會做得更好，把話說清楚，讓大家及時了解我們的方向和進展。

—— Ryan

https://dbushell.com/2025/04/28/denos-decline/

https://deno.com/blog/greatly-exaggerated

https://news.ycombinator.com/item?id=43863937

2025 全球產品經理大會

2025 年 8 月 15–16 日

北京·威斯汀酒店

2025 全球產品經理大會將匯聚互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人，圍繞產品設計、用戶體驗、增長運營、智能落地等核心議題，展開 12 大專題分享，洞察趨勢、拆解路徑、對話未來。

更多詳情與報名，請掃碼下方二維碼。