轉載請註明出處：葡萄城官網，葡萄城為開發者提供專業的開發工具、解決方案和服務，賦能開發者。
原文出處：https://blog.bitsrc.io/what-is-deno-and-will-it-replace-nodejs-a13aa1734a74
Deno是什麼？
Deno v1.0.0已於5月13日正式釋出。
其開發者為Ryan Dahl，他的上一個專案是Node，相信我們大部分人都瞭解。
作為Node之父，Ryan Dahl認為Node自從他把專案移交出去後，Node的走向越來越背離了他的初衷，並且存在著很多無法解決的問題，所以他決心重新開發一個新的專案去解決這些問題，這個專案就名為Deno。目標則是Destroy-node。
那麼，這樣是不是就意味著Deno即將替代Node，成為Node的下一代產品？我們應不應該從現在就開始放棄Node開始使用Deno呢？ 讓我們一起看看。
起源
在2018年，Ryan在柏林進行了一次演講，這是他第二次關於JS的公開演講，第一次再2009，那次是宣佈Node專案的誕生。
在這次演講中，除了主要介紹他認為Node.js的幾大問題和不可避免的許多Bug外，在演講快結束時，他揭開了當時還是個小專案名為Deno的面紗，因為和node命名有著千絲萬縷的聯絡，那時大家認為這個專案就是Node.js v2，它將會解決和完善ry提到那些問題。
兩年後的5月13日， Deno 1.0終於正式釋出了，它是一個全新的服務端JavaScript執行時，使用Rust而不是C++開發，由於Rust原生支援WebAssembly，所以它也能直接執行WebAssembly。基於Tokio平臺(它提供了所有JavaScript所需的非同步操作)，內建V8和tsc引擎，可直接解釋JavaScript和TypeScript。
安全整合
預設情況下，Node.js給你的訪問許可權比較高，這意味著你擁有讀寫檔案系統、對外發出請求、訪問環境變數等行為。雖然作為開發人員，擁有這種級別的訪問許可權對開發過程非常好，但如果你在開發過程中有一點疏漏，將來對你的應用也會產生安全風險。
而在Deno這，預設情況下指令碼不具有讀寫許可權，必須顯式通過命令列引數來啟用或禁用對不同安全功能的訪問。因此，如果需要指令碼能夠訪問/etc資料夾，可以通過下面命令列執行：
deno --allow-read = / etc myscript.ts
這就類似於其他平臺處理安全性的方式。如果你是Android使用者，那麼肯定有很多應用程式要求你允許它們訪問你手機內的不同資源，例如聯絡人、電話、資料夾等，同樣的概念也可以在這裡應用。通過將這些標誌用作執行指令碼的命令列的一部分，你可以提供程式碼所需的許可權。
更完整的標準庫
自從Node的第一個版本釋出以來，JavaScript已經改進了它的標準庫，但與其他語言相比，它仍有相當長的路要走。Deno也試圖改進這一點，它聲稱擁有一個非常完整的標準庫，允許開發人員使用官方工具執行基本任務，而只需要對複雜任務使用外部庫(ala NPM)。
本質上，Deno開箱即用工具為終端文字新增顏色，處理外部資料結構(如Binary、CSV、YAML和其他)，生成UUID，甚至編寫WebSocket。還可以使用其他更基本的模組，例如檔案系統訪問、日期助手函式、http相關函式等等。
整合TypeScript
如果你對TypeScript非常熟悉，那麼使用Deno將會更加容易上手，因為它原生可以直接執行TS。
另外，Deno不需要任何外部工具去支援多語言，它內部會根據檔案字尾自動判斷其使用的語言解釋引擎。
雖然預設情況下Deno會處理很多事情，但您可以使用自己的tsconfig.json檔案覆蓋配置：
deno run -c tsconfig.json [your-script.ts]
預設配置使用的是嚴格模式，因此如果發現任何不合格的程式碼都會立即得到提示。
放棄NPM和node_modules
Deno決定完全放棄NPM和node_modules， 因為npm邏輯越來越複雜，node.js對外部模組幾乎沒有任何安全驗證措施，另外node_modules也越來越臃腫且難以管理。
那麼，Deno是如何處理依賴關係呢？它是通過url載入所有模組的：
import * as log from "https://deno.land/std/log/mod.ts";
所以，Deno不再需要擁有一個集中的儲存庫，之前的package.json也不再需要了，現在通過在名為deps.ts的檔案中包含了模組列表及其各自的URL，簡化了依賴管理。但版本管理控制怎麼辦呢？作者已經想到了，可在URL上指定包的版本，deps.ts的檔案示意：
export { assert } from "https://deno.land/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/fmt/colors.ts";
由於這個檔案的存在，在內部執行時，依賴項將被重新匯出，這就能讓應用程式的不同模組都引用相同的源。
如果您想更新任何模組的版本，可以通過修改deps.ts中URL的版本資訊。另外，雖然沒有了node_modeules目錄，但依賴項仍然會下載並隱藏在你的硬碟中，供你離線使用，如通過需要重新下載，只需在命令中新增—reload命令即可。
還有什麼？
Deno還包括其他特性，比如自動測試器、偵錯程式、檔案監視器等開箱即用的工具。但其中一些只是語言提供的API，您需要編寫自己的工具才能使用它們。
以Deno.watchFS向您提供的檔案監視器API為例，如果你正在尋找類似於nodemon的解決方案，那麼你可以自己構建它。下面是一個解決類似問題的23行指令碼：
最後，它會在短期內取代Node.js嗎？
雖然Deno的很多想法和理念非常好，也確實解決了很多問題。但作為一個從Node釋出之初就開始用的團隊，我認為PHP、Python甚至Ruby(更不用說Java或.NET)都不能與在後端擁有JavaScript和非同步I/O模型相提並論。這些年來，Node(和JavaScript)不斷髮展，以滿足業界的需求。
在我看來，雖然Deno是以Destroy-node為己任而開發的，但就目前來講，Deno取代Node仍不可能，Node的佔有率太高了，生態也足夠完善，基本屬於想要什麼功能都能在社群中找到，所以基本無需擔心。而Deno還在孵化初期，企業很難去放棄已經成熟的技術轉而投入更大的精力使用它。但它未來的前景還是令人期待的， 也許在越來越多的行業頭部企業分享過它們的使用經驗後，Deno的存在也會越來越為人所知。