這是《為什麼我從 Python 轉戰到 Node.js》這篇文章的後續。《為什麼我從 Python 轉戰到 Node.js》寫於一年多前，主要是說因為我對Python感到失望於是打算嘗試Node.js。
一年的內部CLI工具，客戶項目和更新公司產品的歷練，正是我所學到的東西。不僅是Node，JavaScript也很不錯。
易於學習，但不可能完全掌握
Node很容易學習。特別是如果你已經懂得一些JavaScript知識的話。用Google搜索一些初學者教程，擺弄一下Express，然後你就可以開始你的征程了。然後你會意識到你需要選擇一個數據庫。沒問題，我們可以搜索NPM。哦，那裡已經有不少優雅的SQL軟件包了。之後你會發現所有的ORM工具爛極了，而基本的驅動程序是你最好的選擇。現在，你被困在了實施冗余模型和驗證邏輯中。在那不久，你開始編寫更復雜的查詢，並開始迷失在callbacks中。你終於沖出了callbacks地獄，並開始使用promises庫。現在，你差不多可以“promise化”所有事情，並且美滋滋地小酌一杯。
所有這些是想說明，Node生態系統感覺像總是在不斷前進中。卻不是用一種很好的途徑。“勝過”舊工具的新工具似乎每天都在問世。總會有一個新的閃亮的東西來替代另一個。你會驚訝於這種情況的發生有多麼容易，你和社區看上去都在鼓勵它。你使用Grunt！？每個人都使用Gulp！？不要等待，現在就使用本地NPM腳本！
包括瑣碎代碼——即不超過10行代碼——的軟件包每天都數以千計地從NPM下載。說真的！？你需要用於數組類型檢查的依賴關系？並且這些軟件包被一些大型工具，例如React和Babel所用。
你永遠不可能用一種極快的速度掌握一些東西，更不要說潛在的依賴關系的不穩定了。
處理錯誤時，祝你好運
以前使用其他語言如Python，Ruby或PHP的你，還在期望拋出和捕獲錯誤，或甚至是從函數返回錯誤作為錯誤處理的簡單的方法嗎？Node可不這樣。相反，你需要四處傳遞錯誤在你的callbacks（或promises）中——對，不拋出異常。直到你了解的不僅僅是callbacks，並且試圖遵循堆棧跟蹤，這才不起效用。更不必說，如果你忘了在錯誤上返回callbacks，那麼它就會繼續運行並觸發另一錯誤設置，在你返回最初的錯誤設置之後。你需要讓你的客戶多加一倍的錢以彌補用來調試的時間。
即使你設法想出了針對自己錯誤的堅實標准，你也不能確認（而不讀取源）你安裝的許多NPM軟件包遵循相同的模式。
這些問題導致了“catchall”異常處理程序的使用，這樣就會記錄問題。請記住，Node是單線程的。如果有什麼東西鎖定了該進程，那麼一切就會轟然倒下。但是使用Forever，Upstar和Monit很酷，不是嗎？
callbacks，promises還是generators！？
為了處理callbacks地獄，錯誤處理和通常難以閱讀的邏輯，越來越多的開發人員已經開始使用Promises。這基本上是編寫看上去像同步碼但沒有瘋狂的callbacks邏輯的一種方式。不幸的是，沒有任何“標准”（一切都像在Javascript中其他東西）用來實施或使用Promises。
現在最明顯的庫是Bluebird。它相當不錯，速度快，又能剛好完成工作任務。不過，我發現不得不封裝需求到Promise.promisifyAll（）特別有黑客范。
在大多數情況下，我會使用優秀的async庫，以避免callbacks。這感覺更自然。
最後，我對於Node的經驗是，Generators變得越來越流行。我並沒有深入了解Generators，因此無法給出太多的反饋。非常期待聽到大家關於Generators的經驗。
糟糕的標准
最後一件令我沮喪的事情是缺乏標准。每個人對上述個要點該如何處理似乎都有自己的看法。Callbacks？Promises？錯誤處理？構建腳本？無窮無盡。
那也只是抓住了表明的東西而已。似乎彼此之間也不同意如何編寫標准的JavaScript代碼。不妨快速Google檢索“JavaScript編碼標准”，你就會明白我的意思。
我意識到很多語言都沒有嚴格的結構，但它們通常卻都具有由語言的實際維護人員創建的標准指南。
我認為只有一個確實有助於JavaScript，它是由Mozilla編寫的。
關於Node的最後一些想法
我花了一年時間試圖使用Javascript以及更特別的Node為我們的團隊工作。但是不幸的是，在此期間，我們的時間更多的是花在了攻讀文檔，提出標准，討論庫還有調試瑣碎的代碼上。
那麼我會推薦它用於大規模的產品嗎？絕對不會。其他人有沒有試著這樣做呢？當然有過。我也嘗試過。
但是，我建議JavaScript用於前端開發，例如Angular和React（或者你也可以有其他選擇）。
此外，我認為Node適合簡單的後端服務器，並且服務器主要用於webSockets或API ray。這使用Express很容易快速完成，並且我們正是用在了我們的Quoterobot PDF處理服務器上。這是一個單獨的文件，包含186行代碼，其中還包括了空格和注釋。Node用得真心順手。
回歸Python
你可能會想，現在的我在干什麼呢？好吧，我依然在使用Python編寫web產品和API的主要部分。主要在Flask或Django中，使用Postgres或MongoDB。
它經受住了時間的考驗，有一些偉大的標准和庫，它易於調試並且表現良好。當然它也有它的缺點。但世上沒有完美的東西。出於某種原因，Node抓住了我的眼球，讓我深陷其中。我不後悔曾擁抱過它，但我確實覺得我本不應該花費這麼多的時間在它上面。
我希望JavaScript和Node將來能夠得到改善。我很樂意重新審視它。
請告訴我你的經驗？你有沒有遇到我這樣類似的問題？你是否最終還是決定轉換回到更舒適的那種語言？
