node.js和Deno有什么區別

這篇文章主要介紹了node.js和Deno有什么區別，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

什么是 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/std@0.50.0/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/std@v0.39.0/testing/asserts.ts";
export { green, bold } from "https://deno.land/std@v0.39.0/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有什么區別”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!