Node之父是誰？
沒錯！就是這個叫Ryan Dahl的男人在2009年創造了Node。你看，其實也不是說大神就都沒頭髮，這位大神毛髮不是挺旺盛的嘛！
不過既然是在2009年締造的Node，那麼就不得不吐槽那時候的JS了。在2009年的JavaScript啥樣大家都知道(好像貌似那時候的程序員畢竟少)，ES5.0(不成熟的ES5)在09年年底纔剛剛發佈，而ES5.1(咱們現在用的ES5)在2011年6月纔開始發佈併成爲ISO國際標準。
想象一下即使現在有了ES6 ~ ES2020這麼新的版本，JS依然經常被大家拿來吐槽，更別提那個ES5都沒普及的年代了。
在那時候既沒有合適的異步方式也沒有模塊化，也沒有什麼包管理啥的。那麼這樣的JS寫大型項目或服務端項目簡直就是一場災難，於是乎就產生了各種模塊化方案(Node採用了CommonJS)，也有了npm、node_modules等各種歷史遺留問題。
一方面是當年的Ryan Dahl技術沒有現在好，思想也沒有現在這麼全面、另一方面當年的JS本來就很坑，用它創造出來的東西肯定不會很完美的。
但是如今的JS越來越發展壯大，雖然現在還是很坑，不過比起以前的JS來說簡直強百倍。不僅有了自己的模塊化，還有了Promise、Proxy、Bigint、塊級作用域等一系列非常實用的特性、而且還有更好的TypeScript來爲JavaScript負重前行。而Node的歷史包袱實在太重，即使想支持一下標準的模塊化都不得不把.js變成.mjs以保持兼容。
Deno起因
Node之父並沒有一直在維護Node，他後來離開了NodeJS加入了谷歌，在谷歌他研究的主要方向就是機器學習裏面的圖像着色和超解像技術。雖然取得了一定的成就，但是Ryan Dahl認爲現在的機器學習還很簡單，離真正的人工智能還有着十萬八千里。但是這並不妨礙人們去提升機器學習的技術，因爲他相信，總有一天，人工智能會變得越來越完善。
提到機器學習和人工智能就不得不提python，Node他爸始終不是很喜歡Python，久而久之，就想搞一個JavaScript的人工智能開發框架(以後前端可能還得再學個人工智能)。等到他再回過頭撿起Node.js，發現這個項目已經背離了他的初衷，有一些無法忽視的問題。
這些啥破玩意？那個又是些什麼鬼？原來，他覺得當初自己創建Node時失誤實在是太多了，他甚至還在2018年得JS開發者會上列出了自己設計NodeJS的十個錯誤：
- 沒有堅持使用Promise
- 沒有注重安全性
- 沒有從GYP構建系統轉到GN
- 繼續使用GYP，沒有提供FFI
- package.json以及依賴了npm
- 在任何地方都可以require(”somemodule“)
- package.json 提供了錯誤的module概念
- 設計了軟件界黑洞node_modules
- require(“module”)可以不寫.js
- index.js
爲了彌補這些錯誤，他研發了一個新的項目，用來解決他的十個痛點(其實遠遠不止十個)，這個項目就是Deno。
Deno的技術
Node的底層依賴的是C++，那Deno一樣嗎？
答案是否定，一部分程序員可能還記得Deno一開始依賴的是Go語言，這曾經在GoLang社區掀起了不小的波瀾。
但是好景不長，後來換成了Rust。然後好多人藉機黑Go吹Rust了一番。
至於爲什麼換成Rust，Ryan Dahl說是因爲不想同時存在兩個GC(Go和TS)
Deno的名字
細心的朋友可能會發現deno這四個字母就是node的四個字母兩兩顛倒了一下:
- de + no = Deno
- no + de = Node
顛倒Node字母的寓意是要顛覆Node嗎？
其實也差不多，它的意思是：Destroy Node （毀滅Node!）
看來Ryan Dahl對他的Deno很有信心，我是希望它能真的幹掉Node的，因爲它的優點實在是太過於突出啦！
那麼接下來我們就來看一看Deno的優勢都有哪些：
Deno的優勢
內置tsc引擎，可以直接運行ts代碼(還是要先編譯成JS)。這就不用你每次編寫完ts代碼還要去手動去編譯了，而且也不用再去搭建什麼ts-node之類的了，方便你我他。它的內部會根據文件後綴名判斷，如果是.ts後綴名，就先調用TS編譯器，將其編譯成 JavaScript；如果是.js後綴名，就直接傳入 V8 引擎運行。
由於是用Rust語言開發的，Rust原生支持 WebAssembly，所以它也能直接運行WebAssembly。它的異步操作不使用libuv這個庫，而是使用Rust的Tokio庫來實現event loop。
那麼爲什麼不像Node一樣用C++而是選擇用Rust呢？主要是因爲Rust提供了很多現成的模塊，對於Deno來說，可以節約很多開發時間。也許是看到了Rust提供了很多現成模塊，Deno也決定在自己的項目中添加許多現成模塊。
Deno具有安全控制，默認情況下腳本不具有讀寫權限。如果腳本未授權，就讀寫文件系統或網絡，會報錯。想要讀寫文件系統的話必須使用要參數，顯式打開權限纔可以。Ryan在總結Node的十個錯誤時曾說：V8引擎本身有很好的sandbox架構，但是有時候Node本身卻沒有好好利用，例如有可以直接讀取Memory的例子，或者linter可以直接使用網絡功能等的漏洞。從npm下載了一個包就任由他運行了，這其中存在着很大的安全隱患。
Deno 支持 Web API，儘量跟瀏覽器保持一致。它提供 window 這個全局對象，同時支持 fetch、webCrypto、worker 等 Web 標準，也支持 onload、onunload、addEventListener 等事件操作函數。不像Node，Web API和Node的API不一致只會增加開發者的學習成本。以後window全局對象就可以不僅僅只侷限於瀏覽器環境啦！
Deno只支持ES模塊，跟瀏覽器的模塊加載規則一致。既沒有npm，也沒有npm_modules這個無底洞，同時不支持CommonJS模塊，也不需要package.json文件。所有模塊通過URL加載，比如import vue from “https://vue.org”（絕對地址）或import vue from ‘./vue.runtime.js’（相對地址）。因此，Deno 不需要一箇中心化的模塊儲存系統，可以從任何地方加載模塊。但是，Deno 下載模塊以後，依然會有一個總的目錄，在本地緩存模塊，因此可以離線使用。也就是說其實還是有一個類似於npm_modules的文件夾。
Deno 內置了開發者需要的各種功能，不再需要外部工具。打包、格式清理、測試、安裝、文檔生成、linting、腳本編譯成可執行文件等，都有專門命令，不知道會不會在幹掉Node的路上順便把Webpack也給幹掉。
Deno的劣勢
雖然這麼一對比，感覺NodeJS完全不是對手，但是有一點是Deno暫時望塵莫及的，那就是巨大的生態。
就像C#和Java一樣，他們真的差距那麼巨大嗎？其實並沒有吧，但是流行度差這麼多有很多原因是因爲生態。
就像華爲想搞自己的鴻蒙系統，即使真的能比安卓優秀，但是安卓巨大的生態就足夠領先很多年。當年Windows Phone系統不就是這麼輸的麼？啥軟件都沒有，自然沒人願意賣Windows Phone手機。
Ryan說了，Deno現在不打算對Node做兼容處理，也就是說很多東西在Node能用但是在Deno上用不了，能不能真的幹掉Node就要看廣大造輪子愛好者們了，看看他們願不願意在Deno身上再造一個。
如果React、Vue以後都從Deno身上建生態了，那麼Deno的前途就真的光明瞭，希望那一天能夠早點到來。
重要提示
之前曾經發生過一羣中國程序員以一種類似於貼吧灌水的形式在Deno項目的issue下面大量發：
- 學不動啦
- 求別更新
- 前端太難了
之類，其他issue都被淹沒，導致Ryan直接關閉issue，中國程序員在世界上的形象更加一落千丈。如果學不動了可以不學，不找那種高端崗位就是了，又不是所有崗位都要求你是全棧。
但請不要給全體中國程序員抹黑，謝謝！