為什麼 Node.js 不適合大型和商業專案？

JavaScript 和 Node.js 一直都是這幾年的話題，無論是前端還是後端，到處均可見 JavaScript，就好像爬滿了你全身上下，他們不斷地對你說道「嘿！老兄！快來用我吧！」。

為什麼 Node.js 會這麼夯？主要是因為效能快過於 PHP 和 Python 與 Ruby，寫法簡單又容易，並且前後端能夠使用同個語言當然是最好不過了。不過當然也有人簡單就是因為「潮」（嗨！歡迎加入潮流式驅動開發）。

但⋯⋯若是你只是因為這些緣由而選用 Node.js，你能夠考慮轉往其餘語言了（甚至回到 PHP 和 Python 的懷抱），為什麼？這裡有幾點你須要考慮。

毫無結構性

事實上，Node.js 很適合小型和輕量級專案，但當結構越來越龐大的時候，你會趕上這件鳥事。沒錯，Node.js 是弱型態語言，這也令 Node.js 暴露在不具結構性的問題下，令開發者難以掌控物件所擁有的屬性為何、函式會回傳什麼內容。

就算你的編輯器支援了型態提示，多數情況下他們都是 any（任意），這根本沒有幫助。

說到這裡，你可能會想起 TypeScript，但那只是「一時之選」，用上 TypeScript 會使你的專案變得更加複雜，但結構變得更明確了。然而效能還是 Node.js，那麼為什麼不直接轉換到強型態語言呢？

緣由很簡單，因為 Node.js 的生態完善，是其餘語言所沒有的，但除此以外呢？沒了。

型態難以判斷

若是你曾去面試 Node.js 相關職位的工做，你可能會對 undefined == null 這個問題不陌生，而其答案是 true。

沒錯，在 JavaScript 裡面你永遠無法預料兩個形態是否相等。當然，在你有很多採坑經歷之後這對你來說可能已經不成問題了。

在 CodeMash 2012 中 Gary Bernhardt 所演講的「Wat」影片透過有趣的方式點出了 JavaScript 的型態是很神奇的一件事情。

然後若是你不知道，JavaScript 還有 Set 跟 Map 型態。

文件、註釋不易撰寫

撰寫 Node.js 的文件與註釋是個難題，比起文件，更多專案擁有的是 README，這讓初心者更好上手，但進階開發者則須要花上更多時間查找本身所需的函式。

至於什麼叫作註釋難以撰寫？一般撰寫 JavaScript 註釋的時候會遵循 JSDoc（或 APIDoc）的方式，像下面這樣。

/**
 * Hello 會透過 WebSocket 並向使用者傳遞指定的打招呼訊息。
 *
 * @param  {String} greeting - 欲發送的打招呼訊息。
 * @return {Boolean} 傳送是否成功。
 */

function Hello(greeting) {  
    // ...
    return true
}

看起來不成問題，對吧？頗有條理，又很明確，然而在幾個星期後你就會發現不斷地標記函式的參數、回傳值是多麼累人的事情，過了不久，註釋就會跟不上函式真正的功能，當然你能說這是取決於工程師本身的怠惰，更多能說的是在 JavaScript 中，註釋其實沒有這麼好用。

設想一下你的函式會回傳一個物件，你能夠保持勤勞，寫成這樣。

/**
 * @typedef  {Object} User
 * @property {String} nickname 暱稱。
 * @property {String} username 帳號。
 * @property {String} password 密碼。
 */

/**
 * Foo 會創建一個新的使用者並且回傳一個註冊後的使用者物件。
 * 
 * @param  {User} 來自表單的使用者物件。 
 * @return {User} 註冊後的使用者物件。
 */

function Foo(user) {  
    return {
        nickname: "",
        username: "",
        password: "",
    }
}

然後你就能夠開始回想起你究竟是在哪個文件中定義 User 這個物件了。因此更多時候我會直接打上 @return {Object} User 物件 然後叫其餘開發者本身去看統一集中的文件，因為那樣還更好管理物件結構。

可用函式跟不上時代

若是你是個標準的 Node.js 工程師，你就會經常去看 Node Green，因為你永遠不知道 Node.js 到底支援了這個函式沒有。然而你會看到一堆紅色的錯誤代表還沒有支援。

接著你就會抱頭痛哭，沒過多久，全部的專案都會直接使用 Babel，這能將還沒有支援的函式轉換成相容舊 Node.js 的程式碼，但令程式更長。

套件佔了空間一大半

Node.js 的生態真的很好，然後你就會用上一堆 npm 裡的套件，接著發現 node_modules資料夾比起你的專案大概多用了二十幾倍的空間。

若是你有兩個專案，還會因為版本相容性的問題而多上另外一個 node_modules 資料夾。順帶一提，現在有這麼多的 Electron 軟體，每個軟體都有 node_modules⋯⋯佔用了 100 MB 的空間但實際內容其實只有 10 MB。

額外一點，由於 Node.js 不是編譯式語言，因此當你須要部署 Node.js 專案到伺服器的時候，你還須要執行 npm install（或 yarn install）下載你專案所會用到的全部套件，這會額外花上兩分鐘左右的時間，更別說作持續整合測試了。

回呼地獄

這個問題存在好久了，回呼地獄（Callback Hell）在之前一直是個問題，你可能回想說，這不是早就被解決了嗎，像是透過 Q.js、Async.js？對，但這還沒完。

回想起這個問題的歷史，一直到 jQuery 推出了 Deferred 才被解決，然後最終被一個 Promise 取代。但在那之後人們不滿又推出了基於 Promise 的 Async/Await，接著你就會發現因為有的人腦袋還跟不上，因此一個專案同時出現了 Callback 還有 Promise 跟 Async/Await。

Node.js 推出的新功能一直以來都是用膠帶在填補以往的坑，除非像 Python 2 到 Python 3 那樣的大轉變，否則這些坑可能都還會在吧。

多工異步麻煩

Node.js 預設就是一個程序只使用單個核心（這大概也是為什麼叫作 Node 的緣由），不是不少人都有機會用到 Node.js 中的 Cluster 模塊，一但接觸之後，你就要開始區分 Master 跟 Worker 然後他們是怎麼互相溝通與聯繫的。

到目前為止我對 Node.js 如何發出多工請求、最終取得「全部多工的結果」還不是很清楚。但我能知道的是⋯⋯若是你會用上 Cluster，那麼你就會須要在初期時花上更多時間來有個周詳的規劃（就像規劃微服務那樣）。

後記與逃離 Node.js

其實本來還要寫上 Node.js 在測試方面上的問題，主要是因為 Node.js 沒有內建良好的測試工具與環境，導致須要額外花費時間處理像 Mocha 等⋯的設置問題，不過因為看了看發現已經寫夠多文字了，我想應該也不須要額外補上這一點啦⋯⋯。

不過這也不表明 Node.js 是徹底不須要的，畢竟用在客戶端上還是十分地方便（例如 Webpack）。若是你正在考慮在後端使用另外一個語言的話，不妨看看比起 Node.js 還要更快並且簡短的語言：Go。

• ScaleDrone Websocket 平臺從 Node.js 轉換到 Golang
• Iron.io - 我們如何從 30 臺伺服器變成只須要 2 臺：Go
• 在 Bowery 將 Node.js 換成 Go
• Express.js 做者棄用 Node.js，轉向 Go 語言
• Uber 為何放棄 Node.js 轉用 Go 語言建構高 QPS 服務？
• Node.js 之父 Ryan 推薦你們使用 Go 語言

Go 所內建的工具和環境令開發與測試十分容易，並且效能與部署也極快，撰寫 WebSocket 聊天室和 Node.js 相同，十幾行就能搞定了。若是你有興趣學習 Node.js 或者是其餘語言（並且比較偏向 Web 服務的話），也能夠參考看看。