比較node.js和Deno
前言
如果你一直關註 Web 開發領域，那麼最近可能已經聽到瞭很多關於 Deno 的信息——一種新的JavaScript運行時，它可能也會被認為是 Node.js的繼承者。但是這意味著什麼，我們需要“下一個 Node.js” 嗎？
什麼是 Deno？
要瞭解發生瞭什麼，我們首先需要看一下 Deno 到底是什麼。就像我前面說過的那樣，這是一個新的JavaScript運行時，也就是要執行 JS代碼的環境。它最初是由Ryan Dahl創造的，他在之前曾經為我們把 Deno 與Node.js進行瞭比較。
Ryan在JSConf EU 2018 演講上宣佈瞭 Deno，標題為“Node.js 的十大遺憾”。僅從那條信息中，你就可以知道進展情況。 Deno 是從頭開始創建的，是當前對 Node.js 的更好的實現。
但是 Node.js 有什麼不好的地方？Deno 如何與它更成熟的表兄抗衡？
與 Node.js 的比較
盡管 Deno 和 Node.js 是執行相似操作的類似工具，但它們之間的差異遠遠不隻是名稱的顛倒。
體系結構
讓我們先來瞭解一下 Deno 的內部原理。就像 Node.js 一樣，它基於 Chromium 的V8JavaScript 引擎，並使用事件驅動，非阻塞架構。但是兩者的主要編寫語言有所不同。Node.js 主要使用C ++編寫，libuv作為其異步 I/O 庫，而 Deno 用的是Rust，同樣其使用的異步庫Tokio也是用 Rust 編寫。
對於這些差異如何轉化為實際性能，我們必須拭目以待。就目前而言，根據Deno 的基準，兩者之間的區別是無法區分的，或者說至少是非常微妙的。
ES模塊
你可能知道，Node.js 當前的模塊系統是所謂的CommonJS（帶有require()的那個），盡管ESM（ ECMAScript 模塊（帶有import和export的模塊）成為 JS 的官方標準已有相當長的一段時間瞭，可以追溯到2015 年推出的ES6。當然，Node.js 確實支持 ESM，但是此功能目前（[ v14.xx） 被標記為實驗性的，從而迫使 JS 社區仍然使用 CommonJS 模塊系統 或其他打包器。
這就是 Deno 要推出的東西，它僅支持 ESM 模塊 —— 一個真正的模塊系統！
依賴管理
但是，除瞭 ESM 之外，Deno 還為 Node.js 帶來的依賴性管理帶來瞭更多變化。
基於從有著上百萬個包的npmregistry和類似黑洞的node_modules目錄中汲取的經驗，Deno 采用瞭一種完全不同的依賴關系方法。 Deno 不需要類似npm的 registry 和包管理器，而是直接從 URL 導入並使用依賴項：
import { serve } from "https://deno.land/[email protected]/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
req.respond({ body: "Hello World\n" });
}
然後將下載的模塊不可見地存儲在計算機上的某個位置。是的，這意味著不會再有node_modules！
可是等等！還有更多…或者我應該少說，因為 Deno 還擺脫瞭現在制作的萬能的package.json文件。除瞭deps.ts文件之外沒有其他的替代選擇，它的作用更像是所有外部模塊的重定向排序文件：
export { assert } from "https://deno.land/[email protected]/testing/asserts.ts";
export { green, bold } from "https://deno.land/[email protected]/fmt/colors.ts";
至於 NPM registry，因為 Deno 現在可以從 URL 加載依賴項，所以這與 Node.js 的要求不一樣。但是如果你對這個選項感興趣，Deno 會提供自己的包托管。
TypeScript 和其他功能
是的，你已經看到瞭 ——JavaScript 是使用 Deno 的主要語言，另外還支持TypeScript，。該支持是內置的，不需要類似custom registers的東西或復雜的設置。
但是，除瞭 TS 支持之外，Deno 還內置瞭許多其他有用的工具。它們當中的大多數以命令形式出現，例如fmt、bundle或doc，分別提供代碼格式化，打包和文檔生成等功能。
API
至於 API，Deno 肯定是自己的東西。一切都是用 TypeScript 編寫的，異步 API 僅基於Promise。核心功能被限制在最低限度，而其他所有功能都可以在標準庫中找到。
所以從表面上看，這一切看起來都很好，而且非常有前途，但是當你意識到更改所有的 API 意味著將 Node.js 代碼庫轉換為 Deno 更加困難時，這種愉悅的心情立即消失瞭。可悲的是，所有新的和更好的東西都必須付出代價，對嗎？
安全
最後，安全性是 Deno 最重要的方面之一。與 Node.js 相比，它用沙盒執行的代碼，僅允許訪問系統的選定部分。這意味著通過傳遞適當的標志，可以輕松地限制對磁盤、網絡和子進程等內容的訪問。
那麼，這意味著什麼？
因此，我剛剛以非常簡短的方式向你介紹瞭 Deno 的一些功能，以便你能夠掌握所有內容的要點。你可以根據需要進行更深入的研究（我將在本文結尾放一些不錯的文章鏈接）。
讓我們回過頭來討論這個博客文章的主要問題——這意味著什麼？好吧，主要是因為Deno v1已經在2020 年 5 月 13 日發佈（正好是其首次發佈的第二年）。現在每個人都在問這是否將會成為“下一個大事件”，或者它是否將會完全取代 Node.js。
就個人而言，我認為現在討論這些還為時過早。考慮到項目的規模和社區的期望，該項目盡管已經是 v1 版瞭，但要成為可行的 Node.js 替代者還有很長的路要走。請記住，這些技術（即使存在所有差異）仍然要做同樣的事情，同時必須相互競爭。而且 Node.js 的開發也不會過時（例如基於 Promise 的 FS API變體或 ESM 實驗性支持），這意味著我們很可能會在這個存在兩個 JavaScript 運行時的世界中生活很長時間（說的好像對 JS 開發人員來說是個新鮮事一樣）。並且請記住，我甚至沒有提到龐大的 NPM registry 和生態系統，盡管它們無論如何都不是完美的，但仍然為 Node.js 增添瞭很多價值——這是 Deno 目前還不具備的優勢。
底線
總而言之，Node.js 不會出現在任何地方，並且，如果你要啟動一個用於生產的嚴肅項目，那麼至少就目前而言，最好還是堅持使用 Node.js。話雖如此，但是沒有什麼人（當然不是我）或事情能夠阻止你去使用 Deno，甚至把 Deno 用於嚴肅的項目。看起來它確實像是未來，但是我們根本還沒有到達。
以上就是比較node.js和Deno的詳細內容，更多關於node.js和Deno的資料請關註WalkonNet其它相關文章！