咱們並不須要 Deno

做者：Deno 一出生便帶着光環 —— 它發佈於 Node.js 創始人 Ryan Dahl 的演講「Design Mistakes in Node（幻燈片）」，當時有些人說 Node.js 要涼了，但我不這麼認爲。

原生 TypeScript

其實目前咱們在引擎的「用戶態」去使用 TypeScript 並無引入任何問題，並且給用戶帶來了很大的靈活性。考慮到 TypeScript 不可能離開 JavaScript 的生態 —— 畢竟引擎老是要支持 JavaScript 的；再加上 TypeScript 有不一樣的版本、不一樣的編譯開關，在用戶態使用 TypeScript 能夠說是最好的方案了。TypeScirpt 早晚會成爲 Deno 的歷史包袱。

從性能的角度，在 TypeScript 沒出現以前，V8 已經在 JavaScript 上進行大量 魔法優化 了，能夠說 JIT 出來的代碼並不比其餘靜態類型的語言差太多，是無法簡單地經過 TypeScript 來提高性能的。再加上前面說了引擎總仍是要支持 JavaScript、TypeScript 的運行時語義依然是 JavaScript（TypeScript 並不能保證對象的實際類型在運行時不被修改），因此引擎也不可能從對 JavaScript 的魔法優化切換到基於 TypeScript 的類型來作優化。

包管理器

我一直認爲 NPM 是最好用的包管理器之一，這包括將依賴保存在項目目錄中 —— 在調整一個項目的依賴時沒必要擔憂對其餘項目產生影響；每一個包均可以指定本身的依賴版本，容許多版本並存 —— 在升級一個包的依賴時不會影響到其餘包，每一個包均可以使用新的版本或繼續使用舊的版本；NPM 負責查找和安裝包，而 Node.js 則用相對簡單的協議去使用這些包，它們能夠彼此獨立地升級演進。

能夠看到 NPM 最終極大地減輕了開發者的心智負擔，只要你按照正確的方式去使用它，極少會遇到其餘語言中有關依賴管理的問題。而 Deno 則反其道行之。雖然 Deno 也提供了一些相關的功能（deno cache），但你會發現 Deno 的本意仍然是不但願進行「依賴管理」。

在代碼中包含 URL 是一個很是糟糕的作法（Golang 也是如此），Deno 稱之爲去中心化，但其實它只是從新將使用包的代碼與包的來源耦合在了一塊兒（如今 Deno 提供了一個 官方的代理，但這樣和 NPM 的中心倉庫又有什麼區別呢）。緩存機制也帶來了至關大的不肯定性：package-lock.json 能夠保證每次安裝的依賴是徹底一致的，而 Deno 的 lock.json 只能檢查依賴是否有變化（若是有的話就拒絕運行）。這使得開發者很難控制依賴更新的時機，Deno 則建議將依賴緩存放入 Git。

內建權限系統

一直以來通用編程語言都未曾在語言層面引入權限控制，但確實開源社區也曾報出過屢次惡意代碼的事件，但 Deno 的權限機制至關粗糙 —— 只能在進程級別進行權限控制，我能夠大膽地預言，在幾乎全部的場景裏咱們都須要 --allow-all，並不能對安全起到太多做用。

咱們須要考慮 Deno 的用戶究竟是開發者仍是使用者：對於 Deno 腳本的使用者來講關注的固然是進程級別的權限；而對於開發者我認爲更關注的是第三方包的權限，權限系統應該以包爲單位（然而 Deno 裏並無包的概念了），Node 裏原本也有 vm 模塊能夠必定程度上實現沙盒（但確實很是難以控制）。

並且提及來咱們如今已經有了 Docker（或者更普遍的容器的概念）這種完全的隔離和權限控制機制，業界對編程語言引入一套權限控制已經沒有太大的需求了。

孤立的生態

能夠說 JavaScript 的生態來自於用戶態類庫的充分競爭，Deno 則在 Runtime API 以外提供了 Standard Library（相似 golang.org/x）、提供了全套的開發工具鏈（fmt、test、doc、lint、bundle），在試圖提供開箱即用的使用體驗的同時，也削弱了第三方生態。

在 Node.js 和 NPM 已然成爲 JavaScript 事實標準的一部分的狀況下，Deno 原本能夠經過兼容 Node.js 或 NPM 有一個很是好的開場。但 Deno 卻選擇了和 Node.js 劃清界限，而是兼容了一些瀏覽器環境的 API（如 prompt 或 onload）。

Deno 本身的說法是爲了遵循已有的 Web 標準避免發明新東西，但實際上這些 Web 標準在設計時並未充分考慮瀏覽器以外的 Runtime，何況 Deno 其實也沒能避免發明新東西（這些新東西被放在了 Deno 這個命名空間中）。

小結

Deno 就是這樣一個有着很是鮮明我的偏好的 JavaScript Runtime，它試圖去糾正 Node.js 的一些「設計失誤」、但願給出一種「JavaScript 最佳實踐」，但願提供高質量且開箱即用的標準庫和工具鏈。這些偏好的選擇總會有人喜歡或不喜歡，但除此以外 Deno 實在是缺乏一個 killer featue（殺手級特性）讓一個「理性」的 Node.js 開發者（如一個公司）切換到 Deno。

經過單一文件發行、進程級別的權限控制使 Deno 會更適合命令行工具的開發，但可否與已經普遍用於命令行工具的 Golang 競爭尚且存疑。

做爲一個 Node.js 開發者，我並不以爲 Deno 能夠在將來替代 Node 成爲個人主力開發工具，Deno 更像是 Golang 的設計哲學對 JavaScript 的一次入侵。

原文地址：咱們並不須要 Deno