從 Node 到 Deno：你可能還沒準備好

作者 | PIUMI LIYANA GUNAWARDHANA

譯者 | 核子可樂

策劃 | 丁曉昀

背景介紹

毫無疑問，Node.js 就是目前全球最流行、使用範圍最廣的 JavaScript 運行時環境。但 2018 年亮相的 Deno 同樣引發巨大轟動，憑藉現代功能和高安全性在開發者羣體中瘋狂吸粉。

Deno 跟 Node.js 其實系出同門，都是由 Ryan Dahl 傾力打造。人們將 Deno 看作是 Node.js 的繼任者，而且修復了後者中一些重要的設計缺陷。雖然現代範十足、年輕氣盛，但 Deno 能不能徹底取代 Node.js 仍是個未知數。而且至少就目前來看，這事還八字沒一撇，大部分開發者對 Node.js 的表現仍然表示滿意。

在本文中，我也跟大家探討一下 Deno 的普及速度爲什麼越來越慢，還有人們爲什麼仍然喜歡 Node.js。最後，咱們再對這兩位做一番直接比較。

Node.js 是什麼?

Node.js 是一款人氣極高的服務器端、開源、跨平臺 JavaScript 運行時環境，以谷歌的 V8 JS 引擎爲基礎。自 2009 年發佈以來，它一直在 Web 開發世界佔據着主導地位。

Node 主要關注事件驅動的 HTTP 服務器。在處理請求時，它會運行一個向系統註冊的單線程事件循環，每個傳入請求都會觸發一個 JavaScript 回調函數。這些回調函數能夠使用非阻塞 I/O 調用處理請求。

此外，Node 還能從池中生成線程，藉此解決可能造成阻塞或 CPU 密集型任務。跟大多數通過線程擴展的競爭性框架方案不同，Node 基於回調函數的擴展機制能夠以最小的內存佔用量容納更多請求。

憑藉着異步 I/O 加事件驅動架構，Node.js 憑藉輕量化優勢在可擴展、數據密集型和實時 Web 應用程序中佔據了顯著優勢，使其能夠運行在各類分發設備之上。

Deno 是什麼?

如前所述，Deno 屬於新一代的 JavaScript 框架，旨在解決 Node 中的設計缺陷並提供更現代化的開發環境。根據兩套框架的締造者 Dahl 本人的說法，Node.js 具有三個顯著缺點：

• 模塊系統設計不當，過於依賴集中分發。

• 遺留 API 不夠穩定。

• 安全性設計不足。

據稱，Deno 一舉解決了這三大難題，並帶來更好的使用體驗。

Deno 是一款 JavaScript、TypeScript 與 WebAssembly 運行時，具備安全默認設置。即除非明確啓用，否則其無法訪問文件、網絡或環境。Deno 建立在 V8 JS 引擎、Rust 和 Tokio 基礎之上，採用 Web 平臺標準，始終通過單一可執行文件進行分發，並提供內置的開發工具以實現高效、安全的運行時。Deno 包含一組經過審查的標準模塊，可確保在 Deno 運行時上正常運行。Deno 還支持原生 TypeScript 文件執行，無需額外做進一步配置。

Deno 對 Node: 主要區別

現在，我們對 Node 和 Deno 做一番直接比較。

第三方軟件包管理

藉助 Deno，開發人員可以直接通過 URL 安裝軟件包，而無需藉助 npm 之類的集中註冊表。儘管直接從 URL 處下載軟件包有一定風險——如果託管軟件包的服務器遭到入侵，攻擊者可能會修改代碼以注入惡意功能——但 Deno 提供一種對已下載模塊進行緩存的辦法，能夠有效緩解這方面風險。軟件包能夠以庫的形式被直接導入腳本之內，通過允許直接從任意公共 URL 處獲取並運行腳本，Deno 直接跳過了負責模塊導入的軟件包管理器。當然，從第三方處導入模塊仍可能帶來安全隱患。在這樣的設計下，Package.json 文件和 node_modules 文件自然也沒有存在的必要。

相比之下，Node.js 需要使用 npm 來處理所有軟件包，而且有着龐大的庫和軟件包生態系統。

Deno 的模塊導入機制比 Node 更靈活，允許開發者從任意來源處導入代碼，包括 GitHub 和所託管的任意 CDN 或註冊表。這樣，我們無需經過下載或安裝過程，即可無縫實現模塊導入。

API

Node.js 誕生之時，JavaScript 中還沒有出現 Promises 或者 async/await 的概念，所以大多數 API 在設計上都接受錯誤優先的回調函數。這種方法經常會產生冗長而複雜的代碼。如今，Node 開發人員已經可以使用 async/await 語法，但同時也需要考慮向下兼容性，否則 API 經常會因變更而影響運行穩定性。

Deno 的情況則完全不同。因爲 Deno 已經用上了 await 並支持各種最新 JavaScript 功能，所以這裏根本就不需要封裝 async 函數。通過這種方式，Deno 幫助開發人員簡化了處理流程，能夠將各種面向未來的 API 綁定至 JavaScript promises 當中。Deno 還高度關注與瀏覽器端運行的 JavaScript 代碼所使用的 Web 平臺 API 相兼容，能夠以符合標準要求的方式支持多種流行高級 Web API，包括 Fetch、Web Storage、Web Workers 和 Broadcast Channel，等等。

安全性

提升安全性，也是 Ryan Dahl 決意打造 Deno 的核心原因之一。

Deno 提供安全的沙箱環境，能夠禁止對文件系統的訪問，所有代碼執行也都在這裏進行。在訪問文件系統之前，Deno 始終會首先提出授權請求。

要獲取許可必須藉助命令行參數，以防止運行時在未經開發者同意的情況下刪除任何文件。Deno 中的各命令行標誌都能在運行時上使用，藉此啓用特定腳本的特定功能。默認情況下，這些功能均處於非活動狀態；使用者必須爲腳本可能需要的所有元素顯式設置相應標誌。

這些標誌包括：

• — allow-env 允許環境訪問環境變量獲取、環境變量獲取等功能。

• — allow-hrtime 允許執行高分辨率時間測量。

• — allow-net 允許網絡訪問。

• — allow-read 允許文件系統讀取訪問。

• — allow-run 允許運行子進程。

• — allow-write 允許文件系統寫入訪問。

相比之下，Node.js 向來不以高安全性著稱（編者注：Node.js 20 新的權限模型：提供了 Node.js 中敏感 API 的權限管控能力。Node.js 20 正式發佈，新特性一覽）。例如，Node 對文件系統的讀取和寫入訪問權限無需單獨授予，也不屬於沙箱環境。因此，任何第三方庫都可能因處置不當而引起風險。另外，Node 用戶還需要藉助一系列標準安全措施以防止跨站點請求僞造（CSRF）和跨站點腳本（XSS）等威脅，利用這些機制進行日誌檢查、錯誤與異常管理，以及用戶輸入驗證。

因此，即使大家已經習慣了安全模塊的嚴格約束，Deno 仍是建立安全環境的最佳選擇。

TypeScript 支持

TypeScript 是 JavaScript 的一個超集，允許用戶以可選方式添加靜態類型。Deno 使用帶有緩存技術的 TypeScript 編譯器，實現了對 TypeScript 的開箱即用支持。也就是說，Deno 能夠直接對 TypeScript 代碼進行編譯、類型檢查和執行，無需將其轉換爲 JavaScript。

雖然 Node.js 不像 Deno 那樣能夠天然支持 TypeScript，TS 在 Node.js 社區中也早已成爲廣受接納的語言，所以有現成的 TS 包可供使用。大家可以毫不費力地在 Node 上運行 TypeScript。只要安裝了 Node 和 npm，您就可以通過 npm install -g typescript 命令在設備上全局安裝 TypeScript。接下來，運行 tsc --init 來創建 TypeScript 配置文件，之後使用 TypeScript 編譯器 tsc 即可編譯您的. ts 文件。

如果您高度依賴於 TypeScript 而且願意嘗試新型框架，那 Deno 無疑是正確的選項。此外，在 Deno 中使用 TypeScript 進行開發時，無需進行任何額外的配置。

開發者爲什麼

喜愛 Node 勝過 Deno？

聊了這麼多，可以看到 Deno 明顯爲開發人員提供了不少特殊功能，例如強大的支持系統和原生 TypeScript 兼容能力。其設計策略和豐富的內置工具，都能給開發人員提供高效的運行時環境和積極的使用體驗。

即使如此，Deno 爲什麼還是沒能全面取代 Node？可以看到，Deno 對 Node.js 的替代速度非常慢。儘管有着更現代的框架、也解決了不少設計問題，但開發人員還是更偏愛 Node.js——而且人家的理由也相當充分。

在 Node.js 最初發布時，開發者們就已經開始將其納入實際應用。多年以來，爲了滿足軟件開發社區的需求，Node 發生了一系列重大變化，如今成爲業界使用範圍最廣的 JavaScript 運行時。由於普及度極高，它也建立起了活躍且龐大的開發者社區。Node.js 的軟件包系統以 npm 爲基礎，功能豐富且易於管理。因此，如果大家的主要訴求集中在靈活性和上手簡單度方面，那 Node.js 就是當之無愧的最佳選項。

當然，Node 還遠稱不上完美。在 Node 仍顯落後的各個方面，Deno 都取得了無法否認的重要進步，其中又以安全性和標準合規性爲甚。Deno 的單一二進制模式帶來了遠超 Node 的可移植性，開放模塊架構也有望成爲未來依賴項導入的客觀規範。

哪些因素阻礙了開發者

投向 Deno 懷抱？

儘管 Deno 社區也算活躍，但規模實在不大。專爲 Deno 量身打造的軟件包很有限，Node 兼容層有時候也不夠可靠。如果想要使用特定某個庫，或者需要技術幫助，那選擇 Deno 有可能令您陷入困境。

Deno 的另一個明顯短板，就是缺少第三方軟件包。而且由於成熟度不高，它無法像 Node.js 那樣在現實應用中得到廣泛支持。另外，Node.js 有着極高的模塊化程度。在 npm 的幫助下，用戶可以從單一來源找到大量的庫選項。換句話說，每位開發者都可以輕鬆下載大量軟件包來更新自己的應用程序。

此外，藉助第三方庫，大家完全可以在 Node.js 中實現 Deno 提供的多種功能。所以說，如果我們只是喜愛 Deno 的某些特性，那基本也能在 Node.js 中達成同樣的效果，只是過程中需要多一點額外操作而已。

Node 還有另外一張王牌，那就是簡單好用的權限管理機制。我們可以在平臺上快速收取反饋，無需經過各種授權。Node.js 能以最少的麻煩快速進行編碼，很少需要請求特定權限。因此，它特別適合那些需要定期更新、體量龐大而且涉及豐富專業知識的動態項目。

考慮到以上種種因素，可以看到大多數開發人員對於 Node.js 的現狀基本感到滿意，在短時間內應該也不打算 “叛逃” 到其他框架中去。

與龐大而繁榮的 Node.js 社區相比，如今的 Deno 只能算是 “蹣跚學步” 的程度。它還沒能在實際生產系統中經受全面測試，開發人員也還在適應這種新的運行時環境。當然，必須承認 Deno 有着巨大的發展前景，也確實在安全性、模塊、回調和集中分發系統等層面超越了 Node 的水平。目前，Deno 吸引早期使用者所依靠的主要是大家對於新鮮事物的好奇心。相信隨着時間推移，Deno 背後社區的發展壯大將讓這個項目逐步成爲 Web 開發領域的重量級選項。

總結

在比較了 Deno 和 Node.js 的異同之後，希望大家現在能夠理解 Deno 中蘊藏的巨大潛力，以及開發人員爲什麼對這樣一套優秀的框架顯得不那麼熱心。Deno 無疑將繼續吸引越來越多的關注，我個人也相信它終有一天會成爲能與 Node.js 正面叫板的強大框架。

但軟件開發者始終是以完成任務爲第一訴求，對於工具的選擇必然要基於用例的真實需要。

感謝你願意耐心看完！

原文鏈接：

https://cult.honeypot.io/reads/deno-vs-node-main-differences/

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/fkju9KWgSlh1033P5-a8-A