node相比傳統服務端技術棧差在哪裡？

01-03

限制後端的主要是資料庫的io開銷還是編程語言的性能？同樣作為後端的可選編程語言node相比java c＃差在哪裡？是性能嗎？是社區嗎？是強類型嗎？是積累嗎？為什麼很多人會說node不適合計算密集型呢？

原因

人:

用node的人很多,相當多,而且npm包數量冠絕全場,但是node主要使用者是前端,就比如express這個庫,我覺得一半的下載量是用在了前端框架的服務端渲染和webpack的HMR了,並不是用在了真正的服務端挑大樑的開發中.

還有一點,除了少數node牛人,大部分node使用者服務端知識太匱乏,什麼分層、多線程、並發、IPC基本沒有,操作系統的知識可能僅僅停留在幾個bash命令上,說白了node使用者雖然多但是並不是真正的服務端開發人員(絕大多數是前端順手寫個node),實際上工作中只靠node為生的服務端人員數量很少,導致其在工業界實踐並不如向他社區那樣火爆.

性能:

性能要分兩方面看,一方面是io性能,一方面是計算性能,node安身立命的傢伙就是i/o爆表,事件驅動的特性使得node的i/o十分卓越,不然當初它也不能被發明出來.

cpu計算性能的確是node的軟肋,跟java/c#自然是不能比,但是web開發大多數情況下要命的是i/o,而且node的性能比java/c#差不代表比其他語言差,比ruby/python還是快出很多倍,而且可以調用c/c++模塊來處理cpu密集型任務(python等性能較差語言的通常做法),以下是個性能參考網站.

總而言之node在i/o有其卓越的方面,cpu密集型任務是node的軟肋但不致命.

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=nodelang2=yarv

類型:

我可不可以理解這個類型原因是因為靜態強類型語言可以更好的規避錯誤,提高工程質量,我覺得這個原因應該是比較小的.

一方面typescript+node是很多公司的標配了,雖然typescript只是靜態類型,但是寫起來跟c#幾乎跟親兄弟一樣,在這方面並不是node吃虧的地方.

另一方面,並不是說動態弱類型能否決一門語言,我大PHP不是世界上最好的語言嗎?

積累:

這個問題可以跟人這個原因結合在一起,node的社區一向火爆,但是在工業界的實踐跟其社區火爆比起來差很多,當然不少國內外的大廠已經有一些實踐,比如國內node最牛的阿里,但是讓node獨挑大樑的實踐還是不足,很多情況下是作為渲染層出現,就比如淘寶真正的後端還是java挑大樑,node做渲染.

我們可以類比同時期出現的golang,golang的火爆是隨著業界眾多實踐的成功逐漸火爆起來的,這使得golang在近幾年一年比一年受開發者歡迎,Stack Overflow做的調查里使用者里最喜歡的語言是go,未使用者里最想嘗試的語言也是go,go在雲計算領域積累的足夠多的實踐加上docker這種殺手級應用的加持屬於一步一個腳印火出來的.

node不同,屬於一出來就紅遍半邊天,前端開發者們把整個社區引爆了,但是這麼多年在工業界殺手級別的應用和實踐跟其火爆程度不成正比,反而導致如今勢頭平淡了許多.

做個總結吧:

node隨著發展已經摘掉了很多當初對他的黑點,比如單線程:其實cluster出來很久了多線程的實踐是沒問題的,比如回調地獄:這個隨著es6+普及有無數個解決方案,比如動態類型,typescript很成熟了.

反而node有不少優點,比如i/o密集型,事件驅動,社區活躍,前後端語言統一等等.

node真正的問題不是語言或者類型的問題,而是真正node從業者太少(雖然使用者多),缺乏工業界大量成熟的實踐.

ps: node相關的書也太匱乏了,目前看過最好的就是朴靈的&<九淺一深node.js&>還是4年前的作品,node原理相關,其它node相關的書不是講的太淺就是平庸之作,大量的教你弄個聊天室教你弄個博客,反觀人家java&&<深入java虛擬機&>&,你看看人家的書講的都是啥?

如何讓門檻比較低的程序員也能寫出能用的代碼並且不影響服務的穩定性？如何讓不同的程序員也寫出長得差不多的代碼？

這一點 Node.js 社區做得並不好。

方法論變化太快，成熟的體系還在建立中，目前階段還是算蓬勃發展吧我認為。

很可能你現在學習的東西沒有java那一套那麼保值，因為兩年後社區玩另一套去了。

它差就差在太年輕，跟任何新事物一樣。

但如果說它有沒有什麼本質上的差，程序的角度我認為是沒有，但太多前端藉由node涉足服務端領域，導致代碼質量實在層次不齊，這算不算是node本質上的差，不好說。

瀉藥

不知道

人家都說了，不用就沒發言權，不常用那個，沒啥發言資格。

說個題外的，個人比較欣賞 Node addon 開發者，他們是 Node 名副其實的基石。

在他們眼中，應該不太存在技術棧差之類的東東吧。

本來不想回復的，匿名的那哥們寫的挺好的，雖然不懂他為什麼要匿名。但看到某些回復，不得不說幾句。亂解讀，誤人子弟的事，還是有必要澄清的，以免Node又無端被黑，相信這也是所有佈道者都應該承擔這種除魔衛道的責任。

語言無關，就事論事

沒有領袖，Node 之父用 Go，TJ 也用 Go，都跑了。

1) 語言不是因素，是他想做的事兒變了，但他的心依然還是愛著Koa

TJ轉做Go有很多原因

人家做的基於aws Lambda的基礎設施 https://github.com/apex/apex，選擇Go無可厚非，從架構角度，我還要給他點贊！
TJ對Node.js一直很關注，尤其對Koa框架，看他的Pinned repositories 就知道，另外給Koa提issue被他懟過，也可見他很在意Koa

別亂解讀，誤人子弟

2) Node.js之父在2012年就離開社區的，然而這5年發展的依然很好

狼叔寫過一篇文章請別拿「死」人做文章，

Node.js之父Ryan Dahl在2012年就離開社區的，我們必須要承認他作為創始人的偉大創舉，但不能標籤化，ryan不代表node，從他離開社區後，對於社區而言，他就「死」在曾經的豐功偉績上，未來與他無關！

Node.js之父在2012年就離開社區的，然而這5年發展的依然很好，並無影響。這篇文章本來沒什麼問題，但有些人借位營銷就噁心了。

狼叔說：Node.js不是最好，也不是最差，是性價比比較高的，可惜node做後端一直不溫不火，java，php利益相關，只有新項目用，微服務架構下，會更好一些。很多人node是用錯的，不是用node就什麼都用，分清場景。不誤解，不傳謠，合適自己的才是最好的

但是總有些人想拿這事兒做文章過度解讀，

抽象程度不夠高，對於做業務的人來說這很痛苦。使用者中小白太多，人員素質參差不齊，包的數量多，質量卻呵呵。

這完全是沒邏輯的屁話，看起來沒問題，卻經不起推敲。

抽象程度，所有語言都有這個問題，Go就沒有么？Java、PHP這麼多年小白少么？說人員素質參差不齊，哪個語言不一樣？所以說，這完全是狗屁邏輯。我比較喜歡Ruby社區，是高手和低手兩級分化最明顯。Node.js從2009年到現在才8年，再成熟能成熟到哪裡呢？不拿一個起點比較都是扯淡。

最後說npm，黑的完全不到點上，目前超過60萬個模塊，絕對是社區第一。在眾多包管理器上，我沒見過質量都一樣好的，按照8020原則，60萬里至少有12萬個模塊是不錯的吧，你工作中能用到的會超過三位數么？

所以說質量好不好要看人怎麼選，而不應該賴到npm上。長點心吧。

用來做腳本倒是沒啥問題，做商業開發就處處踩坑了。我沒怎麼用 Node做 Web，因為怕 hold 不住。

沒用過，就別瞎逼逼。

國內國外的成功案例，眼瞎看不到么？我親歷的去哪兒和阿里都在大量使用，我親耳聽到的騰訊大量使用Node，對於李成銀所在的360團隊也是大量使用。

如果說 Node hold 不住，其他語言就能 hold 住？呵呵

如果說人 hold 不住，那我相信，那是水平問題。

目前 Node Web 框架依然是 koa 和 express 類似的架構，中間件沒什麼問題，但是如何組織它們，如何在 high level 層面把控他們卻沒有看到很好的最佳實踐。

沒用Node還嗶嗶框架，不是打臉么？

我們可以根據框架的特性進行分類

框架名稱特性點評

各種框架都經過大廠小廠實踐，別的語言實現的我敢說Node都有了。還有什麼所謂的更好實踐，從2005年rails橫空出世之後，大部分框架都是借鑒ROR，Node就算沒有走到最前面，至少沒有落後於最佳實踐，否則，請給出，否則，請閉嘴，別瞎逼逼。

大公司也是相繼開發自己基於 koa 的框架。

悖論，去哪兒的基於Express用的杠杠的，無任何問題。Node不缺Web框架，Koa雖好，但遷移各種還需要時間，未來是變化的，Koa能否一統天下還猶未可知。可以肯定的是Koa在非同步流程式控制製做的改進，命名為Node下一個Web框架是不過分的。

比如micro，比如fastify，非常多好東西。

不過在我一個 Rails 使用者的眼裡，這些框架還是不夠 high level如果性能要求高，我的選擇肯定是 Go 而不是 Node。

用rails的人還考慮性能么？我不是黑ror的朋友們。rails這樣的神器足夠好，即使ruby以前性能那麼不好，但不影響人家開發很多世界級應用啊。儘管後面有的被替換了，但又怎樣呢？做ror的高手技能都非常全面，ruby和前端和運維都是極其的熟練。當然Node和go也有這樣的人，但普遍偏弱，這不是人的問題，而是產生的時間較短，沒背景的人就不能出現全棧牛逼的能力。

如果真追求性能，我建議用rust寫，如果還想牛逼，用c寫，最好順便把操作系統也寫了。

人還是要有自知之明，做應用軟體和系統軟體是不一樣的思維。傻逼才只看性能呢。

Node 除了親 JS 好像對我沒啥吸引力。但是如果公司非要用我也不反對，大不了自己摸爬滾打找出最佳實踐即可。

沒用過，請繞過。我特別尊重蘇千和朴靈，推動Node在阿里落地，比如蘇千做的cnpm真是功德無量，比如Egg，能夠統一全公司的資源去推動框架落地，可預見大公司阻力。朴靈的alinode解決了性能調優的問題，內部使用的經驗沉澱，對外提供付費服務。

這是人物。做的比說的多，低調如此，也不去惹是非。用德藝雙馨形容不為過。

Node 還有一個好處是 UI 做的好，比如 pm2，比如調試器，畢竟是前端，但這些都不是殺手級的賣點呀。我不是挑語言的開發者。

Node 和 UI有關係么？呵呵呵

Node 對我屬於一個可用可不用位置。不過相信牛逼的你肯定可以玩轉 Node。加油吧少年。我對Node新人的建議是玩一玩可以，

沒用過，就別瞎逼逼。

js已經橫跨3端，pc/h5，移動端（hybrid和組件化），pc client（nw.js和electron，atom和vscode體驗還不錯）

Node補足了js服務端的補足，比如io，比如過於依賴瀏覽器。

1）初衷，server端，不想成了前端開發的基礎設施
2）命令行輔助工具，甚至可以是運維
3）移動端：cordova，pc端：nw.js和electron
4）組件化，構建，代理
5）架構，前後端分離、api proxy
6）性能優化、反爬蟲與爬蟲
7) 全棧最便捷之路

不過要早點轉 Go，因為 Node 並沒有什麼突出的優勢。

Go在伺服器端，並發模型上確實很好。做後端是極好的選型。但在前後端分離或者單體應用里，真的合適么？

前面說了，性能並不是繼續選型的唯一因素，不然ror那些牛人早轉了。我一直的看法是前端離不開node，api層node有優勢，io密集和腳本動態，做api組裝聚合類的非常合適。對於後端服務，Node也是可以的，不過這時的node和go是一樣的，尤其是上了微服務架構，服務是獨立的，和語言無關，按照其特性選就好了，何必扯一些沒用的。

最後說一下Node全棧

每次演講我會都問大家是不是前端，回答「是」的人非常多，我會開玩笑的恭喜大家：「現在的前端就是錢端」，確實，現在前端發展異常的快，而且沒有趨向於類比java里ssh框架的那種穩定，所以未來很長一段時間，還會增長，持續混亂，這對前端來說是把雙刃劍，一方面有很強的壓迫感，不學習就跟不上時代，另一方它也是機遇，能夠帶給更多機會，包括money。

大家都疑惑的一個問題是如何在這樣巨變的時代能夠通過學習來應變，我可以很負責的告訴大家，沒有捷徑，但通過掌握 Node.js 能夠讓你降低這個學習曲線而已，畢竟Node.js是大前端的基礎設施。大家可以看一下，前端的開發過程，模塊化，構建，輔助工具，調優，架構調整，可以說Node.js是無處不在的。

其實，輔助大前端開發只是Node.js的一個非常無心插柳的衍生功能，通過掌握Node.js能夠讓你能做的更多、獲得的更多，甚至可以說有更多自我實現的快樂，在後面的章節會詳細講解Node.js的具體應用場景好處，這也是本書名字里「更了不起的」要去闡述的內容。

綜上種種，就是我一直提倡以 JavaScript 語言為中心的 Node全棧 概念的緣由，JavaScript 覆蓋所有前端，Node.js 擅長做 I/O 密集型的後端，外加輔助開發的各種基礎設施，無疑是工作、學習和成為快速掌握全棧技術最好的途徑。你會的越多，你能做的就更多，你的人生也將會有不一樣的精彩篇章。

補充如下

沒有領袖？

笑死了，根本就是外行，Node的接力棒是 TJ 和 sindresorhus ？ryan走了， Isaac Schlueter接?的好么，然後是TJ Fontaine。之後鬧出了iojs分裂問題，後來促使joyent不得不妥協，成立Node基金會。

現在是純社區玩法，背後是Node基金會。

可以說，任何人離開都不會有特別大影響。鐵打的營盤流水的兵，而已。

TJ是想對Node改進的，但Node的負擔太重了，現有體系和機制改變不是易事，而且也沒有動力促使它改變。很多特性都是意淫的，根本不是Node設計的場景，所以說這些沒意義。響馬大哥的fibjs就是一個不錯的實踐，但為什麼二者不融合呢？。。。。因為沒法真的沒法這樣做。。。

拿 express 和 Rails 對比，是一樣東西么？

我知道不能把 Node 跟 Rails 一起比，因為一個是平台，一個是框架。那我就詳細拿 express 和Rails 比吧。express 可以說是提供了一個 RESTful API + MVC 的框架，本身既沒有 orm 也沒有提供各方面的腳手架（對比 Rails 的 scaffold）也沒有提供任何主觀性的集成（比如你需要自己搭建測試框架）

進一步暴漏無知。express本身只是內核加了幾個實用中間價的微型框架。Rails呢？是一個一站式的頂級Web框架。rails在2005年橫空出世，node是2009年產生，exprss是2010年才有，這個比較客觀么？

謬誤1:express 可以說是提供了一個 RESTful API + MVC 的框架

a）誰說express是RESTful API了？

明顯要自己規約才能實現的，這也意淫到express上。。。sinatra呢，beego，Revel，Martini呢？

express上實現rest可以，但不能這叫。

var express = require("express"); var router = express.Router();


var $ = require("../controllers/users_controller");
// -- custom
/**

 * Auto generate RESTful url routes.

 *

 * URL routes:

 *

 *  GET    /users[/]        =&> user.list()

 *  GET    /users/new       =&> user.new()

 *  GET    /users/:id       =&> user.show()

 *  GET    /users/:id/edit  =&> user.edit()

 *  POST   /users[/]        =&> user.create()

 *  PATCH  /users/:id       =&> user.update()

 *  DELETE /users/:id       =&> user.destroy()

 *

 */
router.get("/new", $.new);

router.get("/:id/edit", $.edit);
router.route("/")

  .get($.list)

  .post($.create);
router.route("/:id")

  .patch($.update)

  .get($.show)

  .delete($.destroy);

module.exports = router;

b）誰說express是MVC了？

express目錄有router和view就算mvc了？呵呵，看看rails，thinkjs，eggjs行么？

├── app.js ├── bin │ └── www ├── package.json ├── public │ ├── images │ ├── javascripts │ └── stylesheets │ └── style.css ├── routes │ ├── index.js │ └── users.js └── views ├── error.jade ├── index.jade └── layout.jade

7 directories, 9 files

c）誰說express是和rails一樣的框架了？

你可以這也理解express只是內核（插件機制） + 幾個常用插件。是一個麻雀雖小，五臟俱全的微型框架。一個連基本約定，orm，腳手架，migrate都沒有的框架也算框架？

express不會直接使用的。大部分情況都是要自己封裝的，如果說直接拿express-generator做事兒，做分析的，那真是用淺嘗輒止形容不為過。

d）說express不如rails

確實不如，本來就不是一樣的東西。ruby誕生自93年，rails誕生2005年，node和express呢？

起點不一樣，比較有意義么？

Node哲學與 Left-pad事件始末，真了解？

Node 社區的哲學是可以把 left pad 作為一個包，這看起來真的很傻。

明明不知道事件始末就亂髮表意見，是否得當？是夠傻的。

2016年3月份，kik是Azer寫的模塊，但Kik同時是手機通信錄的社交軟體，所以這個社交軟體上就無恥的直接說讓Azer把kik名字給他們，Azer不同意，他們就拿律師函恐嚇，並讓npm妥協，所以npm就妥協了

Azer一怒之下將自己在 npm 上的 273 個封包全部撤下，其中就包括 left-pad 封包。一石激起千層浪，依賴 left-pad 的上千個項目包括 babel 和 react-native 瞬間崩潰。大量開發者看著自己項目構建失敗，頓時被嚇尿。

觀點

1）就沒見過這麼傻逼的公司，一個紅包就能解決的事兒，非要用強權，如果對方在改模塊上耗費心血少的話，轉給你也是可以商量的。
2）11行代碼要不要封裝成一個包？

sindresorhus: Containing complexity is not about putting everything in one-line functions/modules.

社區一致認可的結論：你的模塊必須含有一定的複雜性，不然就沒啥意義了。

3）npm上那麼多個模塊，大多數都是無意義的吧？

從我開始講Node.js全棧大約是3月份，那是npm上是25.6萬個吧，截止到2017年3月是45萬個，我想說的是那個包倉庫都是有好有壞，按照80/20原則，數量是也是相當可觀的。總比那些某些語言連包管理機制都不完善的要強太多了吧！

4）迫使npm調整了撤銷策略，模塊一旦發布，24小時之後就不讓撤銷了

If the version is less than 24 hours old, you can unpublish it. The package will be completely removed from the registry.

這世界是完美的？

沒用過別逼逼我不同意，我在做新的項目之前仔細對比了 Node Web 框架與其他框架，發現 Node 的上述問題，才使用了別的。我不認為我一定要用過之後再來逼逼。你也是做過項目的，知道如果一個項目做毀了會有多大損失，我不會為了來逼逼而去做毀一個項目。如果你技術一般，我建議你先別用 Node，因為會讓你的技術更一般。如果你技術很牛，我不需要建議你什麼，你牛你先說。

沒用過就是沒用過，很多精髓的東西如果停留在表面，是不是太膚淺了？哪個框架是完美的？了解敏捷么？敏捷的基礎認知是什麼？

從上面那express和rails比，從對express是rest+mvc的描述，暴漏對node了解太淺。如果說想黑node，我再幫你補二刀，早年robbin范凱，一直在黑node的回調地獄，可是又如何呢？該有多人用還是有多少人用

有種你別裝，裝了就別瞎比比，既想當婊子，又想立牌坊嗎？

至於項目能否做成功，我並不認為是技術的問題。更多的是你對技術的熟練程度，哪個熟悉就用哪個，你哪個自己不熟悉的，做毀了，然後來罵框架，罵語言？這也是神邏輯啊。

狼叔經常說：「少抱怨，多思考，未來更美好」，適用於所有人。

人員參差不齊要說人員參差不齊， Node 社區說第二，有哪個敢說第一？

PHP 好歹也是專註 Web 後台。Node 可笑的地方在於一群前端以為自己會後端就來寫 Web 後台。我沒有數據支持，但是我就是這麼認為的。 Java 後台的新人也是第一天就會專註於後台方面的學習。當然這並不能作為你不使用 Node 的原因，如果你是大神，你不會在乎這個社區有多少小白的。但是我前面也說了，我關注的大神都從 Node 社區走了啊。我為什麼還要進 Node 社區…… 阿里的蘇千我在阿里的時候也有向他請教 Node 方面的知識，我從未否認他們的貢獻，不過我並不會因此捧 Node。

PHP專註於Web 後台，我估計看了這話，鳥哥會哭的很傷心的。Node的人不是可笑，是有追求，慢慢寫著寫著就在成長。

Java 後台的新人也是第一天就會專註於後台方面的學習？呵呵，沒學Java么？去看看core java吧，上來學後台，沒見過。

關注的大神都從 Node 社區走了，這話更扯淡。哪個社區不是這樣的？不同年齡，職位，人生階段，關注點會不一樣的。比如嚴清zensh就從node轉了go，人家職位也不一樣了。再有說話不要用「都」，我舉個例子朴靈，https://cnodejs.org/user/JacksonTian，大家去看看他的最近參與的話題，10天前的。https://cnodejs.org/topic/5a20be0a110a338547d6e371#5a24c72b9178b0a14ac01e1b

最後，再說一件事兒，別老貼金，進了阿里不代表什麼，馬雲說了，三年以上才算阿里人，才有阿里味。向玉伯，寒冬，蘇千，朴靈等大大們致敬。

Hold 不住？

Node 呢，請問我該用什麼資料庫？用什麼 ORM？用什麼模板語言？用什麼做後台任務？如何監控內存？如何分析日誌？如何做分散式？如何做安全？有些人看說用 Node 做業務速度快，Node 的框架就做那麼點低層次的封裝，能不快嗎？你把各種中間件加完試試？每個領域都要自己去找最佳實踐，然後自己集成起來。

先不論對node和express等理解錯誤的問題。

先看狼叔之前的回復 https://www.zhihu.com/question/263855387/answer/273769595

一般，後端開發指的是 Web 應用開發中和視圖渲染無關的部分，但現在架構升級，Node 承擔了前後端分離重任之後，有了更多玩法。從帶視圖的傳統 Web應用 和 面向Api介面應用，到通過 RPC 調用封裝對資料庫的操作，到提供前端 Api 代理和網關，服務組裝等，統稱為後端開發，不再是以往只有和資料庫打交道的部分才算後端，這樣，就可以讓前端工程師對開發過程可控，更好的進行調優和性能優化。

對Node.js來說，一直沒有在後端取得其合理的佔有率。原因很簡單

1）利益分配，已有實現大多是Java或者其他語言，基本是沒法撼動的，重寫的成本是巨大的，另外，如果用Node寫了，那麼那些寫Java的人怎麼辦？搶人飯碗，這是要拚命的。
2）Node相對年輕，大家對Node的理解不夠，回調和非同步流程式控制制略麻煩，很多架構師都不願意花時間去學習。儘管在Web應用部分處理起來非常簡單高效，但在遇到問題時並不容易排查定位，對開發者水平要求略高。
3）開發者技能單一，很多是從前端轉過來的，對資料庫，架構方面知識欠缺，對系統設計也知之不多，這是很危險的，有種麻桿打狼兩頭害怕的感覺。
4）Node在科普、培訓、佈道等方面做的並不好，國外使用的非常多，國內卻很少人知道，不如某些語言做得好。

了不起是個不能隨便說的詞兒，對於 Node.js 來說，簡化並發編程，用了不起來形容並不過分，在2009年橫空出世時，確實是獨一無二的。但在今天，已經8歲的 Node.js 有了更多、更為廣泛的應用場景，它已經遠遠大於當初設計時的初衷了，我覺得用更了不起來形容已經不過分了！

你這個問題，很明顯暴漏了自己的問題就是上面的原因之3。

開發者技能單一，很多是從前端轉過來的，對資料庫，架構方面知識欠缺，對系統設計也知之不多，這是很危險的，有種麻桿打狼兩頭害怕的感覺。

不懂架構，不懂資料庫，還沒有明白人帶，那你用啥框架，語言能好呢？

1）復用已有基礎設施，很明顯比自己造輪子好。別動不動就java已死，xx已死的，冰凍三尺非一日之寒
2）微服務架構下，你需要多複雜？

不懂不可怕，別裝懂。

UI 是 User Inferface，意思是 Node 社區做的工具的外觀（UI）都很漂亮。

pm2 的 UI（命令行界面）我就很喜歡，Node 內容 Chrome 調試（界面）我也很喜歡，這是 UI，我不是說 GUI。程序員之間說 UI 難道不是既包括 GUI 又包括 CLI 嗎？這只是對於術語的誤解而已，不重要。

各位看官自己判斷這句話吧。

所以 NodeJS 社區很明智，多多模仿其他成熟框架是對的。但我直接去看你模仿的框架就好。？

舉例，我想學日語，結果發現日語里有漢語的影子，於是我去學了漢語？是這邏輯么？

水是原子組成的，幹嘛喝水呢？去喝原子啊，反正有很多途徑。。。

JS 全棧

我不知道這有什麼意義？為了全棧而全棧？Java 二十年前也有一樣的口號，然後呢？而且 JS 現在已經很奇怪了。

目前看js是最容易實現全棧的途徑，沒有之一。我很喜歡ror，但同時學2種還是略難。其他就更不要說了。Java是跨平台，能和JS一樣么？你真的了解從applet到awt到swing到他們衰亡的歷史么？不見得吧，說話還是要有理有據的。

全棧是信仰，是一種積極的人生態度。何謂為了全棧而全棧?我看到的更多的是大家積極的學習，努力的向提高成長。在技術變化如此快的今天，我們不是更該如此么？我尊重每一個有全棧信仰的人，我也祝福你們，未來是你們的。

關於語言他回復的2個點

我對Node新人的建議是玩一玩可以，不過要早點轉 Go，因為 Node 並沒有什麼突出的優勢。
我寧願用 Java 都不會用 Node.js，除非工資特別高

一會扯go，一會扯java，難道對這門語言很熟悉的？還是純粹為了挑起語言戰爭？還是為了培訓機構站台？

大家姑妄言之，姑妄笑之就好，別認真，認真你就輸了

朴大說過：「為什麼非要嘗試去說服傻逼」，可憐之人必有可恨之處，但不容許有人黑我Node。

穩定性還不行，畢竟V8是為瀏覽器設計的引擎。

跑Web應用沒啥問題，做好集群，掛了自動重啟，用戶也感覺不到。

關鍵應用就不行了，只能相信JVM。

我感覺知乎上存在一個「搬弄話題是非」門派，明知哪壺不開就偏要提哪壺，然後讓別人吵吵嚷嚷的，自己看熱鬧。

技術這東西就沒有完美的，能用就用，不能用就換一個試試。多大點事兒？

用 Node 的人沒多少是真的懂端到端（end-to-end）的架構師級別人物吧，大多數就是懂瀏覽器端加上 web 伺服器端的人。如果一個基於 Node 的 web 服務做大了，那肯定要面臨這樣一些問題：

* 單機 QPS 多少？需要多少機器來應對峰值流量？需要冗餘多少機器？機器之間如何共享狀態？

* 如何做負載均衡？在網路模型的第幾層做負載均衡？做多少層的負載均衡？負載均衡請求失敗是怎麼處理？

對於只有瀏覽器端和 web 伺服器端經驗的人來說，這些問題都沒接觸過，很多時候只能說「這難道不應該是雲平台幫我解決的嗎？我寫好代碼部署就應該能跑啊。」

一個新業務在做技術選型的時候顯然不會只考慮是不是大家都能寫 JavaScript。對於大公司來說，往往一開始就要考慮流量有多大，如果新業務特別成功流量激增應該如何應對。這不是一句「雲平台幫我解決」就能應付過去的。這時候必須由有端到端架構經驗的人來做決定。

有端到端架構經驗且有 Node 經驗的人少，那意味著本來大家就不會傾向於選 Node。如果沒有明顯的好處，誰會願意為一項沒經驗的技術打包票啊？當然是選擇已經有成功經驗的技術啊。

其實很多語言都經歷過相似的階段。一開始就是好玩的膠水語言，能很方便把不同的積木粘連起來，但誰也不知道如何能用它來做一套大規模系統。然後有各種企業和組織嘗試利用，最終有一家一不小心做大了發現上了賊船下不來了，只好被迫搞明白怎麼用這門語言做大規模系統。沒人走過的路有人第一次走通之後，後面就好走了。

PHP 原本也很爛，但 Facebook 就不幸上賊船了，後來發現服務如此成功不解決性能問題公司必然發展不下去，所以被迫去解決。當時也有多個團隊競爭解決這個問題，有用 Python 重寫也有用 Java 重寫的，但最後 PHP 轉譯為 C++ 的 HPHP 成功了。如果不是有 Facebook 高速增長的商業利益驅動，HPHP 會被發明出來嗎？很可能不會，然後後繼 PHP 自身的優化也不會跟進地那麼快。最後 Facebook 把 PHP 做成一門新的強類型語言 Hack 也是有切實的需求驅動的，沒有需求一門語言就是玩具。

看到總是一堆前端的「後端大神」各種宣揚nodejs，就應該能明白，不是單純技術棧的問題，而是用nodejs的工程師沒有後端經驗的問題。

如果有了，幹嘛非要弔死在nodejs上呢，之前各種吹噓的統一技術棧，全棧工程師，幾年過去了來回蹦噠的還是那麼幾個人。

語言的差距根本不重要，做為一個後端工程師，不會點java，python，groovy，go神馬的嗎，語言本身就是工具，什麼場景選用什麼工具，很正常啊。

而且重點要考慮不要有太多異構，維護起來太麻煩。

還要考慮開發者群體。

還要考慮第三方是否支持提供對應的sdk。

還要考慮是否有遺留系統。

這些都要考慮進去才好做一個架構選型，對不對。

nodejs最適合的場景還是提供小型的工具服務，前端工程師自己一個人什麼都能做，不需要了解太多後端的知識，會讀寫db，用個緩存就可以搞定的場景。

輕便，簡單，快捷，在這個領域裡最大的優勢就是真的可以是全棧~php都比不上。

但反過來說，你讓一個android工程師寫java後端試試？

另外再補充一句，很多人說後端工程師不想讓前端的人做後端，是怕搶了自己的飯碗。

一直都感覺這是有多無知才能意淫出這種場景。

go出來之後，用go最多的還是以前後端那幫人吧。

nodejs如果真的是各種6，原來的後端工程師一定一窩蜂的轉去啦~

我打100個賭，你一個前端做後端，和一個java轉nodejs，最容易的一定是後者~

反過來是angularjs帶著一堆後端正兒八經的搶了傳統前端的份額，也就是css這部分是大多數後端搞不定的事情。

但這又什麼意義呢？

就算你真的是大神，還是要分工種開發，一個是成本，一個是效率，一個是規範。

這三者決定了在稍大點規模的情況下必須細分崗位職責。

來說說實戰體會，NodeJS 開發網路伺服器的缺點：

需要熟悉各種設計模式，處理包與包之間的依賴關係
用JavaScript開發很難遵循一套規範，最後的代碼很容易變成揉雜了各種版本特性，各種奇淫巧技，很難重構，很難升級的快餐。
一大半時間都要看各種庫的源代碼。有些庫根本是一個引用樹，要搞明白它基本的邏輯，可能要遍歷上百個包。
各種包對傳統的回調，官方的Promise，還是第三方的類Promise態度不一致。
全家桶，不管項目大大小小，基本上會載入幾個功能類似的包。
空值的問題很難控制，很容易導致請求長時間掛起，沒有任何提示，問題很難排查。
性能上的跟蹤和調試，因為難以重構和引入的第三方庫太多，非常麻煩和艱巨。
缺乏強大的開發工具，不適合團隊合作。
總的來說NodeJS適合一些測試性，原型性，或者說小項目。

這個問題下的答案讓我很想笑，說實話，沒有一個是真正用過node的，這麼隔空喊話有意思么？

哪個平台最早實現ev？

哪個平台是純非同步實現？

而py的tornado是在什麼時候？php的swalo又是什麼時候才有的？

你們若是真正的後端程序員，自己心裡沒點那啥數么？

你們炫技時候才會用的mapreduce架構，概念本身就是從函數式借來的，node裡面的每一個函數我們都得這麼實現。

你們有幾個java工程師會去研究RxJava和響應式編程的？我們大量作用在會話中。

說性能的，拜託，按鍵精靈py和工具庫php好意思和v8比性能？真是滑天下之大稽！

http://cnodejs.org/topic/591d8866ba8670562a40f296

有答主倒是提到了node的事件循環和密集計算問題，說node不適合密集計算。好，且不說密集計算的需求有多大，誰告訴你node生態沒有密集計算能力的？

https://github.com/Microsoft/napajs

微軟napa.js是個javascript多線程框架，js本身也可以fork子進程。

至於說node簡單的人，連個獲取命令台輸入的方法都是基於stream，你們那些readLine的真的好意思？

函數式，響應式本來是程序員用來炫技的領域，什麼時候連這個都有人嘲笑了？世道真是變了。

是，你們看見很多寫node的都是前端寫網頁兒的，但是他們寫的真的是node么？最多用用打包工具，真要弄個完整後台跑都跑不起來。

還是你們都認為函數式只是用個lambda?

各個平台跟著node學ev，才讓你們訪問淘寶不再和訪問校園網一樣卡死，飲水思源，黑node你們良心不痛么？

https://cnodejs.org/topic/58eee565a92d341e48cfe7fc

看來真的需要科普一下了。

和語言性能相比資料庫的io開銷對後端性能影響更大，語言本身性能在開發中可以忽略，如果一門語言在性能上有問題，估計沒有人會用吧。
後端語言node和java，C#比差在哪裡，我個人覺得是生態和人。java和c#發展這麼多年生態要比node要好。而且國內那些推node的人大都是前端，那些推node的人很厲害，但是那些人畢竟是少數，國內大部分前端對後端開發了解程度估計也就crud吧（甚至有批人都沒有意識去學習node，最近和一個人交流node屬不屬於前端問題，對方認為node在前端中用不到，尷尬），而學習java和c#伺服器開發的人本身從事伺服器開發多年，所以從伺服器開發的總體素質而言，肯定java和C#那批人有優勢。另外從招聘角度而言，招java的人才更容易一點。
node為什麼不適合計算密集型，我們先看一下node底層非同步庫libuv的架構

這個是libuv的事件循環，我們常常說node是單線程的（其實並不是，因為有個線程池用來處理file io，dns查詢等，linux下線程池和主線程的通信可以通過eventfd來實現），主要是因為這個事件循環處於一個線程中，我們寫的node代碼都是在這個線程中跑的（主線程），比如setTimeout的回調和http server的request事件的回調。

libuv首先檢測是否有timer事件滿足條件，如果有的話就調用對應的回調；然後依次檢測pending、idle, prepare類型的事件（這裡本質就是隊列，隊列中每個元素包含一個需要執行的函數，如果隊列不為空就執行）；接下來是伺服器開發比較重要的，如果在開發過程中創建了一個http server並且listen了，那麼poll for I/O過程中需要檢測當前是否有新的請求，之前的請求是否有數據來（Linux下主要是通過epoll實現），如果有的話，就觸發對應的回調；事件循環中後面的東西就不講了。了解了這個過程我們就可以解釋為什麼node不適合密集型計算了，如果任何一個我們寫的回調計算過多（執行時間會比較長），那麼一次檢測事件循環的時間就會比較長，也就意味著Poll for I/O的頻率就會降低，也就是說單位時間對於http等請求的處理能力降低，意味著單位時間交給線程池處理的各種io減少，可能導致伺服器資源沒有辦法充分的被利用；另外我們寫的回調函數都在主線程運行，也就是說這些回調函數都是按照一定順序在主線程運行的，一個回調函數執行完之後才能執行下一個回調函數，這樣會導致系統對用戶處理的並發能力減弱。舉個例子，如果一個http Server的request事件不做任何io處理，就單純的做數值計算需要消耗100ms，現在有100個http請求，那麼處理這100個請求就需要100ms*100=10s，所以node不擅長計算密集型的任務。

這種問題還能吵……你只需要把堅持nodejs後端最最棒的人直接拉黑就可以了。

為什麼？這是官方自己說的，你自己去官網看看，make it lightweight. 啥是lightweight?net有說自己輕量化嗎？java, c艹有說自己輕量化嗎？

誰說自己輕量化？

synapse說自己輕量化，OSB說自己輕量化嗎？

sqlite說自己輕量化，oracle有說自己輕量化嗎？

基本常識都沒有，簡直IT愛好者

對於手裡只有一把鎚子的人，什麼東西都只能看作釘子

個人理解node強項：對創業型公司友好，對前端開發友好

node的弱項：你把上面的反過來想想看

不是node本身差在哪而是大家對node的期望太高了

1.node本身才發展不久和Java php這些老傢伙比較起來還是非常年輕的羅馬不是一天建成的我們前端有耐心等node完善那一天

2.node的非同步這東西會導致以往的開發經驗不好用

3.大家本來對node的期望就是快速開發一些中小型的後台非要強行Java這些對比沒什麼必要語言各有優勢 node的優勢是省成本一個中小型後台完全不需要新招後端前端團隊自己就能完成

現在node開發需要的是經驗希望有更多更優秀的開源項目

好處是寫起來方便。壞處就是因為方便引發的控制力差，體現在類型安全控制困難、並發處理困難，同步處理困難，性能優化困難等幾個方面。隨便用用也就算了

工具也能秀出各自的優越感也真是醉了，為這個爭風吃醋真是看不清事態，某些人正在偷笑呢

貴圈最大的能耐該不會是這種你吃曲奇，我吃奧利奧，我比你牛逼的小學生思維嗎？

真正的階級對立是開發和項目經理、和產品經理、和運營、和大老闆的關係，我是他們的牛和馬，任憑他們宰割，卻自己在搞內訌，他們看著樂呵，最後還是人家拿大頭。

還不趕快升管理、再不成做個小公司的開發小負責人，從此走上管理的道路，技術只是入行的敲門磚，在絕大多數行業都是如此，還是搞好領導關係才是出路。

技術再牛逼，老闆說好，讓你多接幾個項目，也不在乎你能完成的怎樣，只要能快點賣出去賺錢，誰在乎你用啥技術呢，哪個順手用哪個咯。你出完力氣，嫌你貴，把你拋棄掉，用更低的工資再找個新手，維護那些項目，有開發需求的時候，再招一個就是了。

唉，命啊！

node主要差在所謂傳統服務端技術棧開發對它的信心。

捫心自問大家都是做Web的，計算密集能有多少？其實大部分瓶頸都在IO。

然而所謂「傳統服務端」的自我中心作祟，非得給非主流平台來強行找到沒成主流的理由。其實還是Paul Graham所說的blub語言。

其實跟@bhuztez很久之前說的現象一樣：

Node明顯寫得比傳統技術棧快，好你不適合計算。

Erlang明顯比傳統技術棧跑得快，好你可讀性差，開發困難，不適合大型項目。

到頭來傳統技術棧還得手動優化C10K。創造了更多主流崗位來維持主流。

我在的上一家公司（納斯達克上市，公司名字就不透露了），前端在用node，後端也在大量使用node做很多事兒，各個部門基本都有涉及node服務開發。目前我在一家新公司，也同樣如此，其他部門不清楚，至少我所在的部門在web伺服器中node伺服器扮演重要角色，聽說隔壁部門也貌似在用meteor做寫東西。

目前市場node作為服務端的角色滲透率已經很廣泛，甚至在有的公司，其中部分業務直接用node替代了其它語言用作服務（比如阿里），所以如此黑node，確實感覺很過激，可能真正理解了的人或團隊，才會真正的會用吧，沒有最好的一說，只有誰更合適。

另外，最近發現美團的服務架構中也使用了Koa

圖借於https://mp.weixin.qq.com/s?__biz=MjM5NjQ5MTI5OA==mid=2651747208idx=1sn=b9fc5430049e201c8973126bde8bc202chksm=bd12aac58a6523d32c8d3cbebde0f1c9056909c383fc8fa50ec3f612c83eb0f7b96209100717mpshare=1scene=1srcid=1214XNsVVOSJqBjN1KUvpOzB%23rd

曾經用過C#,Java,Node實現過一些不算太複雜的業務系統。

技術棧整體很難比高低。要綜合團隊，技術特性，業務模型複雜，業務增長以及變化來看。

我們把業務系統範圍局限在：有一定並發的，對高可用性有一定要求的，無狀態的。

整體上node，c＃，java技術棧有一定差異，但都是無關痛癢的。

1。標準化上，後端細分的編程環節，Java的標準化做的比較好，其次微軟，node很差。比如最級別的資料庫訪問，node都沒有一個官方的標準，node整體的API明顯是比較簡單。

但標準這玩意，也不是強制，民間跟風也能形成標準。

2。編寫難度上，C＃ java一般都採用線程池作為後端的執行模型，大家都用同步的方式編寫，對於入門相對簡單。Node只有非同步模型，讓開發人員深入理解，callback，promise，async 和閉包並沒有那麼容易。

3。執行環境，Java和C＃的虛擬機做得已經很完善，Node的虛擬機還是面向客戶端環境，目前都沒有專門針對服務端做優化。

4。threadlocal，在這業務通用或者支撐功能如監控，日誌等，node缺少threadlocal是一個很大的制約，同樣Golang也是一樣。

其他如IDE，debug，代碼分析，CICD，社區，強類型都是各花入各眼

至於很多人會說node不適合計算密集型，也從側面證實Node的使用者大多便前端，cs基礎比較薄弱。

語言的設計跟語言的實現是兩碼事，一種語言速度的快慢，一般是指該語言最牛逼的實現的速度。語言的實現是一個資金密集性的產品，只要肯砸錢，語言設計再難也能跑的飛起來。node的V8，是目前最快的腳步語言的實現，非本地編譯語言中，僅此於JVM，CLR平台。秒殺php，ruby，python。pythond不是大量用在AI領域？

Node不適合計算密集型，是指不要把任務的分發和計算放在一個Node線程里，避免計算密集任務阻塞整個系統。解決的是自己稍微設計任務分發模塊，將密集計算任務限制在獨立的node進程池裡，node主進程負責統籌所有任務的分發以及IO任務的處理。

同樣誤認為java C＃適合計算密集型，也很容易把系統搞死。

真正計算密集型的任務，其實C也搞不懂，或者說cpu也搞不懂，一定上Gpu或者特定晶元。

打開應用伺服器監控看板，CPU利用率10%都算高，真的cpu飆升時，一般也是GC導致的。

總結：如果技術負責人真的是一位，精通後端的Node(JS)工程師，也可能精通前端。把業務功能all in在node其實沒啥問題。關鍵是懂Node的後端工程師不好找，