Deno會在短時間內取代Node嗎？

轉載請註明出處：葡萄城官網，葡萄城爲開發者提供專業的開發工具、解決方案和服務，賦能開發者。

原文出處：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的存在也會愈來愈爲人所知。