🦕你聽到Deno的吼叫聲了嗎？
什麼？你問Deno到底是唸Deno還是Deno？
我都唸Deno，但官方唸法是Deno。
昨天（Day18）聊到既然doGet不適合我原本想應用的場景，那就乾脆玩玩看Deno吧！
🔰還沒碰過Node.js、沒有商用需求的新玩家，可以試試看更易用的Deno。[^1]
👨💻對於網頁開發場景有商用需求的讀者，建議還是繼續投入時間在Node.js。
ℹ️正文主要是陳述我當時的主觀偏好，想要客觀介紹的可以參考rainbow9502さん於2020年鐵人賽的這幾篇文章。
Deno有著Node.js的作者Ryan Dahl的光環，我能信賴Deno這個專案會有一定數量的志工願意貢獻，不至於幾年後就死於理想。
可是，當時剛嘗試doGet失敗，基於微疼的感受，我決定先來比較一下還有哪些類似的競品也在挑戰Node.js。
於是，我查到了競品Bun，並在線上找到一位熱衷於Bun的德國工程師。和他聊了一下，他非常直白地說：碰Deno是在浪費時間。
他認為，Deno的安全性沒有必要，不會有誰想把專案遷移到Deno上面，Bun不論在工作上或是side project上，就是快。
實際上查了一下，也的確如此，例如Deno被人詬病偏離了初衷，開始兼容npm，多了一個中間層，變得不再那麼純粹，反而Deno本身的功能沒什麼進展。以網頁開發來說，類似React的Deno Fresh[^2]有一陣子停滯了很久沒人更新。[^3]
稍微了解Bun派的開發者觀點後，我當時依然還是選擇Deno。
因為，既然我只是下班時間想玩玩，而非為了職涯發展[^4]，我也暫時沒有像那位德國工程師一樣需要處理高併發、低延遲的系統，那我覺得試圖改善安全性痛點的Deno更值得一試。
Deno試著對齊W3C與WHATWG制定的Web平台標準，幾乎採用跟瀏覽器環境一致的語法與API。[^5][^6]
所以，身為前端開發者，使用Deno會感到比較親切，不用額外學習Node.js特有的全域變數，還有那些舊時代的遺產。
回想起我剛碰React、CRA，第一次import時，弄不懂以下這些的差異：[^7]
import React from "react";
import { Box, Grid } from "@material-ui/core";
import { initializeApp } from "firebase/app";
Deno全部統一成瀏覽器環境的方式，把路徑透明化：
import { pascalCase } from "https://deno.land/x/case/mod.ts";
// 也相容npm（建議指定套件版本）
import { say } from "npm:cowsay@1.6.0";
雖然如今我已經習慣Node.js，但是我依然覺得Deno對於新手玩家更友善。
Web1.0時代，一堆人動不動就掛變數或函式到全域，導致全域「汙染」與衝突，所以很常使用第二週（Day10）提到的IIFE方法，直到ES6才追加了DER來解決這個問題，並於2020年才統一全域物件的入口globalThis。[^8]
Deno則更乾淨，所有Deno特有API都集中於Deno這個全域變數底下。我覺得真的是很棒的設計，許願未來的新環境也都採用這樣的設計。[^9]
雖然Deno仍然無法真的解決JavaScript生態系最脆弱的npm ecosystem資安痛點，但就Ryan所述，他想讓Deno更Webby、更去中心化。[^10]
最顯著的就是Deno所謂的沙盒系統，具體來說，使用者執行所有腳本時，必須額外輸入指令給予權限。[^11]
Deno還主打內建TypeScript，如果只是小專案，可以不用再額外配置。
不過，我對這一點還好，就我自己應用的場景，還沒真的對TypeScript感到必要。[^12]
那Deno目前有什麼優勢場景？我覺得是寫CLI工具。
雖然Deno在網頁開發場景，我覺得還沒有成熟到可以商用。不過，Deno有deno compile等機制，安全性也更好。推薦想練習做CLI工具的讀者可以玩玩看Deno。
或跟我一樣只在prebuild階段試試看；又或者反正GAS環境就是一個什麼都沒有的生態系，乾脆未來發展其它社群套件時，就從Deno開始吧？
那一天我在線上跟網友閒聊時，發現、呃、我不確定Deno到底唸Deno還是Deno。
我查了一下[^13]，在JS Fest 2019，Ryan唸ㄉㄟ ㄋㄡ，但到了TSConf 2019，Ryan妥協改唸ㄉ一 ㄋㄡ。
所以，總之，ㄉ一 ㄋㄡ才是官方發音，但我撰文的這個當下，還是習慣唸ㄉㄟ ㄋㄡ。[^14]
[^1]： 例如你可以用Deno開發套件，再透過dnt轉成npm套件，同時兼顧主流的Node.js生態系。
[^2]： Fresh是全端框架，基於Preact這個輕量化React。
[^3]： 此外，Node.js 20+也逐步採納Deno的一些設計理念，就我的觀點，有點像JavaScript採納TypeScript、CSS採納SCSS。
[^4]： 為了工作就乖乖先熟練Node.js，不要跟我一樣休假日都在碰些有的沒的。
[^5]： 可參見官方文件：Web Platform APIs。
[^6]： 我原本想說，Node.js一家獨大時，不像瀏覽器需要協商一個業內標準，那為什麼現在Ryan重新來過，反而主動去對齊標準？現在想想，Node.js剛被發明出來的年代，fetch等標準根本就還不存在。所以是瀏覽器沒有對齊Node.js，乾脆Deno回過頭去對齊瀏覽器並兼容Node.js。
[^7]： 好吧，其實我前陣子用Vite玩PWA遇到各種路徑時又再次困惑……顯然我基礎很爛😝
[^8]： 可參見第一週（Day03）對於全域物件的簡介。
[^9]： 說到底，就是開發者規模變大，必定會遇到的問題吧？跟SCSS後來推出 @use / @forward一樣，也是為了避免團隊協作時，大幅汙染全域。可能其它更大規模場景的語言的開發者們早就視為常識？終歸，這些都是嘗試，去讓一大群開發者們能夠更好地合作一個或數個大型專案。
[^10]： 會不會導致生態碎片化？我覺得聯邦宇宙似乎是比較可行的方式，而非極左地完全去中心化。這可能不是技術的問題，是治理的問題。
[^11]： 隨著大AI行銷敘事，湧入越來越多連自己生成的low code都不願意讀的新玩家，這時Deno相對更嚴謹的權限機制，是否顯得更有價值？
[^12]： JavaScript相較於其它語言的特性是：型別是由值決定，而非變數。儘管微軟試圖建構一套超集輔助方案，但仍然改變不了JavaScript的本質。React本身也還不像Vue對型別有那麼好的支持，我想用TypeScript多是為了用可以直接import json等額外feat，而非型別系統。
[^13]： 哇，我真的很愛浪費休假時間在幹這種事。
[^14]： 我真的覺得這個reddit討論串很好笑，推薦給大家。
iThome鐵人賽
看影片追技術