最近 deno 要發 1.0 了，引起不少人的注意。恰巧今天團隊內又有同學分享了一下 deno，所以想發表一點個人看法。
開始還是對 deno 充滿期待的，但等了兩年發現並沒有什麼令人興奮的特性，反而槽點很多。
node 的標準庫有很多歷史遺留，我是很支援把 callback 風格的 api 早點替換掉的。但是指令碼語言的標準庫是要跟著執行時一起發布的， 提供乙個像 golang 那樣大而全的標準庫可能並不是乙個好主意。而且 js 社群存在多種程式設計風格，維護乙個過大的標準庫是很難的， 不利於生態發展。
相容瀏覽器要適可而止，window 全域性物件真不是乙個好主意。沒接觸過前端的可能還會以為是支援了 gui。為了相容而把一些沒有的概念強加進來， 最後也只是【盡量相容】，平台**還是要寫的，真沒多大意義。
deno 拋棄package.json的設計不見得會更好，可能會帶來更多問題。package.json確實是被過度使用了，裡面放了過多的資訊。但是沒了這個描述檔案，一些相關的資訊只能放到每個指令碼檔案裡， 這對單檔案庫沒什麼大影響，但是對比較大的庫就會有大量的重複。 通過帶版本號的 url 來引入包是乙個糟糕的設計，現在前端專案都不會這麼引用 js 檔案。把版本號寫在原始碼裡對公升級包來說是一大問題， golang 已經在這條錯誤的道路上開始回歸了，deno 還要再走一遍嗎？
那個執行時拉取依賴的特性更雞肋，前端專案大家都不會相信外部 cdn 上的**，更何況後端？
關於去中心化，這個從何談起，npm 的倉庫是中心化的，但 npm 的包並不是中心化的，你可以把 npm 包以多種形式發布到網際網路上給大家使用的， 只不過最後大家選擇了中心化而已。
看著似乎挺好，但這並不是乙個普適需求，僅適用一些特定場景。作業系統本身已有許可權控制，再加上 docker 等虛擬化技術，已經可以做到很好的隔離了。
這個和標準庫一樣，官方指定會減少分歧，但是也會扼殺創新。 官方的不一定是最好的，也不應定是最適宜的，也不一定是最積極維護的。 沒有像 google 那樣的爸爸，不要動不動就官方提供。 你提供了工具，能保證積極維護嗎？bug 能及時修嗎？有需求能給支援嗎？提了 pr 能及時 merge 嗎？ 沒有一定的財力支援，一切還要靠社群。
搞不明白為什麼要原生支援 ts，難道要在 repl 裡寫 ts？ ts 的型別資訊可以給引擎提供一些優化資訊，但是應該不會有人為了這點效能搞乙個 ts 的引擎出來。 反正都要轉義，為什麼不轉義好再執行？ts 在表達能力上又不比 js 強。
deno 最明智的一點就是用 rust 來寫，相信 deno 的作者們最後會發現 rust 寫起來比 ts 爽多了。
Url字元轉義
一 為何進行url字元轉義 如果你的表單使用get方法提交，並且提交的引數中有 等特殊符的話，如果不做處理，在service端就會將 後面的作為另外乙個引數來看待。因此，需要對url字元進行轉義。例如表單的action為list.jsp?act go state 5 則提交時通過request.ge...
url轉義字元
url轉義字元原理 如果表單的action為list.jsf?act go state 5 則提交時通過request.getparameter可以分別取得act和state的值。如果你的本意是act go state 5 這個字串，那麼為了在服務端拿到act的準確值，你必須對 進行轉義 預備知識 ...
url轉義字元
url轉義字元 url轉義字元原理 如果表單的action為list.jsf?act go state 5 則提交時通過request.getparameter可以分別取得act和state的值。如果你的本意是act go state 5 這個字串，那麼為了在服務端拿到act的準確值，你必須對 進行...