前言

如果你一直關(guān)注 Web 開發(fā)領(lǐng)域，那么最近可能已經(jīng)聽到了很多關(guān)于 Deno 的信息——一種新的JavaScript運(yùn)行時(shí)，它可能也會被認(rèn)為是 Node.js的繼承者。但是這意味著什么，我們需要“下一個(gè) Node.js” 嗎？

什么是 Deno？

要了解發(fā)生了什么，我們首先需要看一下 Deno 到底是什么。就像我前面說過的那樣，這是一個(gè)新的JavaScript運(yùn)行時(shí)，也就是要執(zhí)行 JS代碼的環(huán)境。它最初是由Ryan Dahl創(chuàng)造的，他在之前曾經(jīng)為我們把 Deno 與Node.js進(jìn)行了比較。

Ryan在JSConf EU 2018 演講上宣布了 Deno，標(biāo)題為“Node.js 的十大遺憾”。僅從那條信息中，你就可以知道進(jìn)展情況。 Deno 是從頭開始創(chuàng)建的，是當(dāng)前對 Node.js 的更好的實(shí)現(xiàn)。

但是 Node.js 有什么不好的地方？Deno 如何與它更成熟的表兄抗衡？

與 Node.js 的比較

盡管 Deno 和 Node.js 是執(zhí)行相似操作的類似工具，但它們之間的差異遠(yuǎn)遠(yuǎn)不只是名稱的顛倒。

體系結(jié)構(gòu)

讓我們先來了解一下 Deno 的內(nèi)部原理。就像 Node.js 一樣，它基于 Chromium 的V8JavaScript 引擎，并使用事件驅(qū)動，非阻塞架構(gòu)。但是兩者的主要編寫語言有所不同。Node.js 主要使用C ++編寫，libuv作為其異步 I/O 庫，而 Deno 用的是Rust，同樣其使用的異步庫Tokio也是用 Rust 編寫。

對于這些差異如何轉(zhuǎn)化為實(shí)際性能，我們必須拭目以待。就目前而言，根據(jù)Deno 的基準(zhǔn)，兩者之間的區(qū)別是無法區(qū)分的，或者說至少是非常微妙的。

ES模塊

你可能知道，Node.js 當(dāng)前的模塊系統(tǒng)是所謂的CommonJS（帶有require()的那個(gè)），盡管ESM（ ECMAScript 模塊（帶有import和export的模塊）成為 JS 的官方標(biāo)準(zhǔn)已有相當(dāng)長的一段時(shí)間了，可以追溯到2015 年推出的ES6。當(dāng)然，Node.js 確實(shí)支持 ESM，但是此功能目前（[ v14.xx） 被標(biāo)記為實(shí)驗(yàn)性的，從而迫使 JS 社區(qū)仍然使用 CommonJS 模塊系統(tǒng) 或其他打包器。

這就是 Deno 要推出的東西，它僅支持 ESM 模塊 —— 一個(gè)真正的模塊系統(tǒng)！

依賴管理

但是，除了 ESM 之外，Deno 還為 Node.js 帶來的依賴性管理帶來了更多變化。

基于從有著上百萬個(gè)包的npmregistry和類似黑洞的node_modules目錄中汲取的經(jīng)驗(yàn)，Deno 采用了一種完全不同的依賴關(guān)系方法。 Deno 不需要類似npm的 registry 和包管理器，而是直接從 URL 導(dǎo)入并使用依賴項(xiàng)：

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" });
}

然后將下載的模塊不可見地存儲在計(jì)算機(jī)上的某個(gè)位置。是的，這意味著不會再有node_modules！

可是等等！還有更多...或者我應(yīng)該少說，因?yàn)?Deno 還擺脫了現(xiàn)在制作的萬能的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，因?yàn)?Deno 現(xiàn)在可以從 URL 加載依賴項(xiàng)，所以這與 Node.js 的要求不一樣。但是如果你對這個(gè)選項(xiàng)感興趣，Deno 會提供自己的包托管。

TypeScript 和其他功能

是的，你已經(jīng)看到了 ——JavaScript 是使用 Deno 的主要語言，另外還支持TypeScript，。該支持是內(nèi)置的，不需要類似custom registers的東西或復(fù)雜的設(shè)置。

但是，除了 TS 支持之外，Deno 還內(nèi)置了許多其他有用的工具。它們當(dāng)中的大多數(shù)以命令形式出現(xiàn)，例如fmt、bundle或doc，分別提供代碼格式化，打包和文檔生成等功能。

API

至于 API，Deno 肯定是自己的東西。一切都是用 TypeScript 編寫的，異步 API 僅基于Promise。核心功能被限制在最低限度，而其他所有功能都可以在標(biāo)準(zhǔn)庫中找到。

所以從表面上看，這一切看起來都很好，而且非常有前途，但是當(dāng)你意識到更改所有的 API 意味著將 Node.js 代碼庫轉(zhuǎn)換為 Deno 更加困難時(shí)，這種愉悅的心情立即消失了。可悲的是，所有新的和更好的東西都必須付出代價(jià)，對嗎？

安全

最后，安全性是 Deno 最重要的方面之一。與 Node.js 相比，它用沙盒執(zhí)行的代碼，僅允許訪問系統(tǒng)的選定部分。這意味著通過傳遞適當(dāng)?shù)臉?biāo)志，可以輕松地限制對磁盤、網(wǎng)絡(luò)和子進(jìn)程等內(nèi)容的訪問。

那么，這意味著什么？

因此，我剛剛以非常簡短的方式向你介紹了 Deno 的一些功能，以便你能夠掌握所有內(nèi)容的要點(diǎn)。你可以根據(jù)需要進(jìn)行更深入的研究（我將在本文結(jié)尾放一些不錯(cuò)的文章鏈接）。

讓我們回過頭來討論這個(gè)博客文章的主要問題——這意味著什么？好吧，主要是因?yàn)镈eno v1已經(jīng)在2020 年 5 月 13 日發(fā)布（正好是其首次發(fā)布的第二年）。現(xiàn)在每個(gè)人都在問這是否將會成為“下一個(gè)大事件”，或者它是否將會完全取代 Node.js。

就個(gè)人而言，我認(rèn)為現(xiàn)在討論這些還為時(shí)過早?？紤]到項(xiàng)目的規(guī)模和社區(qū)的期望，該項(xiàng)目盡管已經(jīng)是 v1 版了，但要成為可行的 Node.js 替代者還有很長的路要走。請記住，這些技術(shù)（即使存在所有差異）仍然要做同樣的事情，同時(shí)必須相互競爭。而且 Node.js 的開發(fā)也不會過時(shí)（例如基于 Promise 的 FS API變體或 ESM 實(shí)驗(yàn)性支持），這意味著我們很可能會在這個(gè)存在兩個(gè) JavaScript 運(yùn)行時(shí)的世界中生活很長時(shí)間（說的好像對 JS 開發(fā)人員來說是個(gè)新鮮事一樣）。并且請記住，我甚至沒有提到龐大的 NPM registry 和生態(tài)系統(tǒng)，盡管它們無論如何都不是完美的，但仍然為 Node.js 增添了很多價(jià)值——這是 Deno 目前還不具備的優(yōu)勢。

底線

總而言之，Node.js 不會出現(xiàn)在任何地方，并且，如果你要啟動一個(gè)用于生產(chǎn)的嚴(yán)肅項(xiàng)目，那么至少就目前而言，最好還是堅(jiān)持使用 Node.js。話雖如此，但是沒有什么人（當(dāng)然不是我）或事情能夠阻止你去使用 Deno，甚至把 Deno 用于嚴(yán)肅的項(xiàng)目?？雌饋硭_實(shí)像是未來，但是我們根本還沒有到達(dá)。

以上就是比較node.js和Deno的詳細(xì)內(nèi)容，更多關(guān)于node.js和Deno的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論