Deno 意味着什麼？

時間 2020-05-20

標籤 deno 意味着什麼简体版

原文原文鏈接

做者：Arek Nawo
翻譯：瘋狂的技術宅javascript

原文：https://areknawo.com/deno-why...html

未經容許嚴禁轉載前端

若是你一直關注 Web 開發領域，那麼最近可能已經聽到了不少關於 Deno 的信息——一種新的 JavaScript 運行時，它可能也會被認爲是 Node.js 的繼承者。可是這意味着什麼，咱們須要「下一個 Node.js」嗎？java

什麼是 Deno？

要了解發生了什麼，咱們首先須要看一下 Deno 究竟是什麼。就像我前面說過的那樣，這是一個新的 JavaScript 運行時，也就是要執行 JS 代碼的環境。它最初是由 Ryan Dahl 創造的，他在以前曾經爲咱們把 Deno 與 Node.js 進行了比較。node

Ryan在 JSConf EU 2018 演講上宣佈了 Deno，標題爲 「Node.js 的十大遺憾」。僅從那條信息中，你就能夠知道進展狀況。 Deno 是從頭開始建立的，是當前對 Node.js 的更好的實現。git

可是 Node.js 有什麼很差的地方？Deno 如何與它更成熟的表兄抗衡？程序員

與 Node.js 的比較

儘管 Deno 和 Node.js 是執行類似操做的相似工具，但它們之間的差別遠遠不僅是名稱的顛倒。github

體系結構

讓咱們先來了解一下 Deno 的內部原理。就像 Node.js 同樣，它基於 Chromium 的 V8 JavaScript 引擎，並使用事件驅動，非阻塞架構。可是二者的主要編寫語言有所不一樣。Node.js 主要使用 C ++ 編寫，libuv 做爲其異步 I/O 庫，而 Deno 用的是 Rust，一樣其使用的異步庫 Tokio 也是用 Rust 編寫。面試

對於這些差別如何轉化爲實際性能，咱們必須拭目以待。就目前而言，根據 Deno 的基準，二者之間的區別是沒法區分的，或者說至少是很是微妙的。json

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 帶來的依賴性管理帶來了更多變化。

基於從有着上百萬個包的 NPM registry 和相似黑洞的 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 目前還不具有的優點。