初嘗Deno，這是我的感受

Deno 是個什么東西？

我發現自己最近的工作效率不是很高，於是快速瀏覽了一下 GitHub 趨勢頁面，看看有沒有什么比較酷的新項目。其中有個項目排名比較靠前，即 Deno：https://github.com/denoland/deno

這個項目很有趣，因為：

• 使用 Rust 開發；

• 原生支持 JavaScript 和 TypeScript；

• 實現了 ES 模塊。

 

我為什么需要它？

我們可以簡單地把 Deno 看成是 Nodejs 的替代品，因為它們解決的是同樣的問題。

不過，Node 目前在與新 API（特別是 ES 模塊）集成方面仍然存在很多困難。所以，Deno 出現了，它旨在實現與瀏覽器相同的功能。

如果我們想要一個可以在瀏覽器和服務器端使用的代碼庫，可能會選擇 Deno。

 

讓我們來試一下

Deno 只是已知語言的另一個運行時而已，所以代碼幾乎與瀏覽器中運行的代碼相同（暫時忽略標准庫差異）。

這是 Deno 文檔提供的一個示例：

import { listen, copy } from "deno"; (async () => { const addr = "0.0.0.0:8080"; const listener = listen("tcp", addr); console.log("listening on", addr); while (true) { const conn = await listener.accept(); copy(conn, conn); } })();

運行它：

$ deno foo.ts
deno requests network access to "listen". Grant? [yN] y listening on 0.0.0.0:8080

在這里還能看到與 Deno 安全相關的內容（我不打算詳細介紹），即我們可以充分控制腳本的權限。

 

一些想法

以下的內容大部分都與技術有關，大多數人可能不會很關注它們，但確實會影響到我們所有人。

我會假設你們已經嘗試過 Deno 了：https://github.com/denoland/deno/blob/master/Docs.md

基礎

如果不去看內部的技術差異和不同的實現，Node 和 Deno 的行為非常相似。

不過，一旦 Deno 足夠成熟，我認為它將成為 Node 的有力競爭者。

想象一下，我們使用一種方式開發所有的項目（包括庫和應用程序），這些代碼在瀏覽器和服務器端都能正常運行。這將是一種驚人的開發者體驗，而 Deno 已經達到這種狀態了。

模塊

Node 現在面臨的一個最大的問題是在嘗試與自己的模塊系統（require）和規范中定義的模塊系統（import）保持兼容時存在很大困難。

但 Deno 不一樣，它並不關心 Node 的非規范模塊系統，只實現了規范中提到的 ES 模塊：

// Deno & Browsers import {Foo, Bar} from './my-module.js'; // Node (CommonJS) const {Foo, Bar} = require('./my-module.js');

對我來說，模塊是 Deno 最重要的部分，因為我們可以在不做出更改或進行重新構建的情況下讓代碼同時運行在瀏覽器和服務器端。

包鎖、manifest 及其他

我認為 Deno 缺少的東西是 manifest，或者文件鎖。

Deno 建議將依賴項提交到源代碼控制系統中，這樣運行時就可以將 imort 與這些文件相關聯，而不是每次都要去獲取它們。

這樣做確實繞過了對文件鎖的需求，但將依賴項提交到 git 有點不方便……

此外，我們似乎還需要保證依賴項 URL 保持不變，這樣才能在不同的構建之間保持相同的依賴關系圖。但是，如果有人更改了 git 標簽或分支，或者 URL，或者 URL 消失了，會怎么樣？未被緩存的構建會出現很多問題，或者依賴項可能會在不知不覺中發生變化。

至於 manifest，Deno 建議創建 package.ts 或類似這樣的文件：

// package.ts export {Foo, Bar} from 'https://foo.bar/branch/some-package.ts'; // mod.ts import {Foo, Bar} from './package.ts';

標准庫

Deno 還只是一個處於早期階段的項目，在它脫離“實驗項目”之前仍然需要大量的 TLC。

我有幾個問題：

• 關於需要包含什么並沒有明確的流程（誰決定引入什么模塊，或者它們提供什么？）；

• 一些模塊推出得似乎很匆忙，datetime 模塊是一個很好的例子，通過一堆條件解析：https://github.com/denoland/deno_std/blob/4b054d69ad3e63e0a07d0df77a973b0ae5e0892d/datetime/mod.ts#L10

• 某些模塊缺乏測試；

• 並非所有模塊都遵循相同的結構、約定等。

我認為這可能是因為它是由一小部分人開發的，沒有遵循任何明確的流程。希望在未來會發生一些變化。

 與瀏覽器相比

由於 Deno 試圖實現與瀏覽器相同的規范，所以所有代碼應該都是可移植的（至少在經過 TypeScript 轉換之后）。這似乎是真的，但仍然存在一些小問題。例如，對於所有的導入，Deno 都需要擴展，但 TypeScript 語言服務目前不喜歡這樣。

我記得在這方面還存在其他一些問題，但我確信所有這些問題都會及時得到解決。

資源搜索網站大全 http://www.szhdn.com

總 結 

總的來說，我認為 Deno 太棒了，向前邁進了一大步。Node 不敢做的（因為對 Node 來說是一個重大變更），Deno 做到了。我們因此得到了一個更清潔、更簡單的可以與瀏覽器完美匹配的解決方案。

我希望它能夠得到充分的關注。最后，我希望到了某個時候，可以在沒有任何問題的情況下使用它，並開始享受單一代碼庫給我們帶來的便利。最后還想說一句，Deno 的 logo 太棒了。