Node之父重構的Deno終於發佈了，它終究會取代Node嗎？

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的前途就真的光明瞭，但願那一天可以早點到來。