Deno 穩定版本大約在 3-4 年前推出。當時，它受到了相當多的關注，因為 Node.js 的創建者 Ryan Dahl 也是 Deno 的贊助人。哈！你沒聽錯。他為什麼要創造一個新工具來和自己的「孩子」競爭？
Ryan Dahl 承認 Node.js 存在嚴重弱點。最初，Node.js 的設計重點是簡單性和靈活性。但這些年來，一切都已經超越了控制。 Node.js 已經發展得非常強大，獲得了更多的關注，當人們試圖將所有東西都打包到這個後起之秀中時，它變得不必要的複雜。
Deno 的誕生就是為了解決 Node 的弱點。然而，在推出之時，它並沒有展現出自己的優勢。它的效能甚至不如 Node.js，更不用說缺乏 npm 支援——這是 Node 最大的優勢之一。這讓事情變得越來越困難。
作為一個好奇的人，我很快就使用 Deno 嘗試了一些程式碼片段，並意識到圖書館系統的不便。 「哇，我最喜歡的圖書館可能需要很長時間才能出現在這個平台上；一切看起來既新又陌生，」我想！
當我開始「拆除並重建」我的部落格時，一切都改變了。經過多次對技術選擇的猶豫與思考，Fresh這個名字出現了。然而，Fresh 需要 Deno 作為其運作環境。之前沒有部署經驗，但認為「這只是一個 JavaScript 執行環境！」給了我更多的信心。下一個故事就是這篇文章。
今天，我總結一下在使用 Deno 時我感覺「喜歡」的 5 點。
Deno 原生支援 TypeScript。這意味著您可以直接運行 .ts 文件，而無需像其他庫通常那樣執行到 .js 的轉換步驟。很多人想知道這和使用 ts-node 這樣的工具來運行 TypeScript 程式碼有什麼不同嗎？答案肯定是肯定的，因為 ts-node 需要 TypeScript 設定檔才能在複雜的情況下運作，而 Deno 則不需要。預設支援 TypeScript，簡化了直接執行 .ts 程式碼的過程。
我經常創建腳本來為自己處理一些小任務。每次建立新腳本時，我總是在選擇 .js 還是 .ts 之間猶豫。當 Deno 出現時，.ts 成為預設選擇。即使在 Node 專案中，當我需要編寫腳本來執行快速任務時，我仍然更喜歡選擇 .ts 並使用 Deno 來執行該程式碼。
隨著我越來越多地參與 JavaScript/TypeScript 項目，尤其是 Node.js，我一直想知道甚至覺得煩人的一件事是…設定檔太多了。每個不同的項目都有不同名稱的檔案。如果專案使用Typescript，則來自package.json、package-lock.js 和額外的tsconfig.js...更不用說我是否需要配置更多東西，例如webpack、vite、tailwind、postcss...天哪！一開始，由於不熟悉，我不得不通過閱讀來了解專案中出現的每個配置文件的意義和用法，邊讀邊默默咒罵“你到底是怎麼能創建數百個這樣的配置文件的？”
當遷移到 Deno 時，我驚訝地發現根本沒有設定檔。這意味著您可以在沒有任何配置的情況下運行該專案 - 聽起來很超現實，對吧？如果有的話，它也只是一個 deno.json 檔案。 Deno 巧妙地消除了許多複雜的配置或將它們放入單一 json 檔案中。打開一個專案真是一種解脫，不用再擔心出現奇怪的名字了！
Deno 一直並且盡可能嘗試支援 Web API。 Web API 是瀏覽器中可用的一組標準化 API。對 Web API 的良好支援可以允許在 Deno 中運行的程式也可以在瀏覽器中運行，遵循一次編寫 - 隨處運行的範例。這為「通用」圖書館開闢了途徑。
如果您曾經使用過 Serverless，尤其是 Cloudflare Workers，您就會知道 Workers 與 Node.js 並不完全相容，因此使用 Node 特定的程式庫可能不起作用。另一方面，如果一個函式庫使用 Web API 或與 Web API 相容，那麼它運作起來會很順利。這也適用於 Deno。
對 Node API 的支援允許 Deno 在 npm 上執行大多數「套件」。這樣，你就可以自由地使用 npm 套件而不必再擔心相容性了。
很奇怪的是，有一個明顯的事實是，當啟動一個 Node 專案時，它會預設擁有所有使用者的權限。這意味著程式可以代表使用者自由存取檔案或執行系統中的命令。相當危險，不是嗎？想像一下，如果你不小心「運行」了別人的項目，而沒有先檢查它，它會掃描你機器上的所有數據，將其發送回某個伺服器，或者加密所有文件以勒索贖金，那麼你的生活就毀了，這是一個無法彌補的錯誤已更正！
Deno 透過在執行應用程式時新增請求權限的標誌來解決此缺陷。權限可以包括檔案存取、互聯網存取…如果程式想要存取檔案系統或連接互聯網，它至少必須要求權限。例如：
$ deno run --allow-read --allow-write --allow-net index.ts
有很多權限需要「請求」；有關更多詳細信息，請參閱安全性和權限 |德諾文件。最快的方法是使用 -A 或 --allow-all 標誌來允許所有權限。
我記得它剛推出的時候； Deno 在程式效能方面似乎落後於 Node.js。具體來說，基準測試顯示了執行相同程式時 Deno 和 Node 之間的差異；德諾總是表現不佳。有一次，bun.sh突然出現了。 Bun 之所以成為一種現象，是因為它在效能方面優於 Node.js。這讓 Deno 顯得更加呆板。
實際上，在使用bun運行一些Node應用程式時，我遇到了很多問題甚至bug。看來包子還沒準備好「生產」。所以當時我的結論是，對於那些熱愛穩定的人來說，Node 仍然是首選。
最近，隨著 Deno 2.0 的發布，我們在性能提升和增強這只「黑色恐龍」的程式設計體驗方面做出了巨大的努力。根據他們發布的最新文檔，與眾所周知的 Node 和 Bun 相比，Deno 在各個方面都脫穎而出。
以上是我在使用 Deno 時喜歡的點。還有一些功能，例如免費提供 Deno Deploy 來部署應用程式。然而，我仍然偶爾會看到一些文章「批評」效能和模組系統，以及與 Node.js 的低相容性。這些限制已在最新的 2.0 版本中解決。我對 Deno 的看法與剛推出時相比有所改變，希望 Deno 未來能得到社群更多的關注，並取得更多的突破。
你呢？你用過德諾嗎？您對這個 JavaScript 運行環境有什麼讚美或批評嗎？請在下方留下您的評論！
以上是我喜歡 Deno的詳細內容。更多資訊請關注PHP中文網其他相關文章！
