@CarlosRen @flyingcodes 两位的建议还是很中肯的，先在外围项目使用，不要试图去替换其他语言，每个语言都有其适用的范围。 也不要轻易的说大话，去证明自己。我就观察而言，越是把node吹得天花乱坠的，越是有可能根本没有深入使用和了解的。因为这些人把node当银弹，以为有了node，自己会javascript，就可以写所谓高性能的网络服务器了，有这种想法的人，在这里恐怕就不在少数，我不怕得罪人，我就实话实说。

要应用一项新技术，对其要进行深入的了解，我用这个技术能够得到什么好处？公司考虑的是综合成本。node网络IO很强，可以节约接入服务器，前后端代码都是一种语言写的，可以节约人员。node的社区支援很好，库的数量巨大，这都是优势。但他的劣势也很明显，首先所谓前后端统一就是很艰难的，前端和后端程序员思维方式差别太大了，就一个内存问题，后端的就要非常紧张，生怕内存泄露，前端现代浏览器都开始用多进程模型，某个页面不行了，杀死就是，泄露的资源操作系统就给回收了。在后端就没有这么好的事情，尤其那些挂在全局变量上的对象，不主动释放，最后都是灾难。前后端编程复杂度也不是一个级别的，前端异步过程少有复杂的很多层的，逻辑上主要是以页面呈现为主。后端要做的异步过程就太多了，跟数据库，跟外部服务器。es6新增了promise和generator能够初步缓解编程难度，但没有从根本上解决问题。异步本身回避不了回调，但异步可以通过适当的变换，隐藏的回调，让异步过程看起来像同步的，generator做的就是这样的变换，但他对回调的调用还是显式的，也就是说，你必须将回调转换成符合能够被generator使用的回调。你的回调过程不再由自己调用，而是通过转换之后由generator形成的框架代你调用。你整个代码本质上还是围绕回调在转，还是由显式的回调驱动执行的。另一种思路是直接用协程来隐藏回调，这种隐藏是在c层面的，javascript层面看不到回调代码，这样整个代码就变得很清晰，也不需要额外的框架去驱动回调执行。在同步代码面前，大家又回到同一个起跑线了。这方面的例子有fibjs，openresty。

我说了这么多前后端的差异，并不是说，前端不能转后端，很多优秀的前端转型成了后端大牛，openresty的作者就是很好的例子。但这个转变过程绝对不是一些人以为的用node做个demo就行了。用node做玩具很容易，做产品很难很难。前端转后端要学的东西太多了，就仅仅是node的源代码，可以学习的东西就有很多，如果要真的使用node，我建议是大家对node有个比较深入的了解，先用node做一些大前端（页面渲染等）的工作，然后在慢慢的深入，我想，用到一定程度，大家自然对node就有了一个清晰的定位。

上面讲到人的问题，node最不缺的是人，最缺的也是人，一个公司能招聘到前后端都很强的是非常幸运的，这样的人才价格高，招资质平庸的又不堪用，node不是会javascript就能干好的。这中间其实就有成本的问题，我是情愿招聘价格适中专业的前端，然后再加专业的后端，还是花大钱招聘全能强人。这里没有对错，只有取舍。但幸运的公司能有几个呢？出得起大钱的公司又有多少呢？

我的回答或许能够解释node看起来有点火，但又不那么火，公司都是很现实的，尤其是原来技术上比较成熟的公司，就会更加考虑这些因素。用node创业公司，创业部门肯定高于成熟公司和成熟部分，但吃螃蟹不是没有代价的，这中间的酸甜苦辣也只有他们自己知道了。

@cnlile

后端每个人的理解概念是有很大差别的，我也没有要表达，node不适合做后端的意思，主要观点是谨慎，不要拿node当银弹。

nodejs和python之间要选择的话，我也会选择nodejs，因为我对python不了解。最关键的就是你的项目后端和你朋友项目的后端，这个到底后到哪个程度了，我比较关心这个问题，这个问题也关系到node的定位问题。省政府千万元还是千万并发？这个概念差远去了，你提到了是政府项目，这个项目对稳定性，安全有要求么？为什么不做纯node？而是要和java并存？这肯定是有原因的。

在我的概念里，node就是大前端，起浏览器与核心后端数据的桥接作用。

你们是怎么解决同步代码去写异步代码碰到的问题的？有没有一些好的经验，我个人的经验是，没有显式的异步才是最好的异步，所有需要显式变换的异步都是过渡方案。如果可以让你写同步代码，又能享受异步带来的性能好处，你还会选择node么？

@yuyang041060120

理性，中肯。

技术选型不能任性，要根据项目实际情况综合考虑。小项目随便搞，大项目，团队作战的，技术选型不符合团队实际情况，后果大家可以想象。

@i5ting 未来竞争对手会越来越多，如果node还有优势的话，那也仅仅剩下群众基础了，我个人并不看好前后端统一，尤其不看好javascript这门语言的发展。感觉javascript在走c++的老路，语言不再简介，为了解决现有的问题，又引入了一堆问题，学习成本在增加。我个人更喜欢像c这样小而美的语言。

javascript发展到现在，历史包袱太重了，一个语言一味在自己身上添加东西，一味的做加法是很无奈的。node的未来并不由node本身决定，而是由javascript语言的发展决定的。node各个方面都很好，libuv网络库很好。跟nginx等比较，虽然算不上最优，但整体还凑合。nginx已经支持TCP_REUSEPORT特性，也开始支持http2.0，这些东西node不知道有没有做一些工作了。

可替代node的项目现在是多如牛毛，几年前node或许是很闪亮的，但现在已经不是了，这是个事实，有了很多强力竞争者。

我自己也在用libuv和lua做一个网络框架，lua端没有任何异步代码，全部是同步，基本原理是学openresty的，用协程在c层隐藏了异步回调。我认为形式同步实现实质异步是大势所趋，node是不是可以继续发展下去，要看javascirpt语言本身的发展，是否支持协程，是否能够实现形式同步的代码（不需要任何转换的，promise和generator还是需要转换，也不需要async/await关键字）。

nodejs最大的矛盾就在于，我们的确需要高性能，高并发，但我们业务逻辑却都是顺序执行的，显式的异步代码会搞乱这一切。在性能和编码难度之间我们要做一个权衡。所以中小项目，业务逻辑不太复杂的时候，node的劣势并不明显，但一旦复杂起来，还得回归同步代码，这个世界上，优秀的同步代码程序员比优秀的异步程序员多得多。这个矛盾本质上就是我是愿意找几个牛人还是愿意多买几台服务器的矛盾。钱或许不是问题，但优秀的人却很难找，一些公司考虑的就是这个问题。但如果退一步，不让node做复杂的业务，专心做大前端的活，这样的人又容易找了，价格还便宜，这就是个取舍的问题。

@flyingcodes

nodejs起了个大早，现在跟其他后起的网络框架比却落后了，这其实跟很多人不能正视nodejs存在的问题有很大关系。

nodejs刚出来的时候，回调和协程之争，现在javascript语言本身发展路线证实了，到处回调是有危害的，要限制，要转换，如果这个问题在早几年被重视，也许javascript标准就不是现在这个不伦不类的样子，对异步转同步就会有更好的规划。node最根本的问题还是性能和编码难度的矛盾，性能现在已经没有优势了，编码难度虽然有改变，但核心还是没变。性能上没有优势，现在很多人又拿javascript的群众基础和库的数量安慰自己，这个会javascript和会写后端代码区别大去了，库数量巨大，真正有用，真正敢用的也就那几个。

node即便要用，也最好用在合适的地方，那些鼓吹前后端通吃的，那是没有体验过 @yakczh 所说的虐人后劲。

@flyingcodes @alsotang

一些人不知道什么心态？大家在这里讨论讨论，怎么就扣上帽子了？这里谁黑node了？明白黑什么意思么？真心没有黑node的意思，就是实话实说，有的人神经过敏了，说得不对指出来，大家讨论就是。

大家要明白一个道理，一个技术如果大家真心喜欢，即便有人黑，人还是会用。如果一些人老是神经过敏的，觉得人家提出一些node的弱点就是黑node，这是不是反而说明内心不太自信呢？node的问题，大家心里都清楚，就看愿不愿意说实话。这里面毕竟关系到一些人的利益。

node真好，就不要怕黑，自信点，况且也没人黑，别神经过敏，做技术心态很重要。

@CoderIvan

我对nodejs的批评主要还是希望他能够更好的发展，并不是像有些人扣上一个黑nodejs的帽子。

nodejs现在在我看来是libuv被javascript绑架的产物，既然nodejs选择了javascript，在短时间内做出改变是不现实了。nodejs刚出来的时候，为了追求性能，将所有异步都用回调来表达，当时那么鄙视同步代码的ndoejs，现在却不自觉的走回了同步的老路（callback，async/eventproxy库，promise，generator/yield，async/await都越来越接近同步了）。nodejs能火，很大程度上是因为javascript和v8，语言大腿和企业大腿都抱上了。其实回调异步其他语言上早就实现了，并不是什么不得了的新技术，c，c++，java，python等都有自己的异步库。但为什么这些库都没有火？nodejs却火了？

javascript是一门典型的入门容易精通难的语言，群众基础好，小而美的项目比比皆是，很多优秀的前端创造了大量的库。如果某前端强人出来创业，首选肯定是nodejs，而nodejs群众基础创造的茫茫多的解决方案又为这些项目做了很好的支撑，尤其是在创业前期需要快速出产品原型的时候，nodejs绝对是适合的。

nodejs第一个适合场景是创业项目的原型，中小规模，业务逻辑不复杂的项目。

javascript这门语言招靠谱的人都难，招强人那是更难，这个想必在用的公司都有感受。这个是由这门语言决定的，入门容易精通难，人才价格当然高。这在国家鼓励创业，大量资本支持的黄金时代都不是事，工资高点，出活就行，但一旦出现萧条，这钱就是最大问题。（我说这个事情肯定很多程序员是不高兴的，是要骂我的，大家不就是想工资高点，股票多点，你这种人怎么大过年的来泼冷水，肯定是嫉妒羡慕了，我无法辩解，我就以人无远虑必有近忧来强行洗地吧，我看得准不准得让时间说话，现在用nodejs创业的公司，不成功的自然是死掉，成功的多半会引入其他框架或语言来完善业务逻辑）。

nodejs第二个适合的场景是作为服务器渲染层，替代原先PHP，JSP干的活。

这也是很多人整天宣称nodejs干掉PHP，java的原因，我觉得做技术的还是沉下心来去看看阿里这些应用nodejs的公司用他做了什么？人家有用nodejs做业务逻辑么？边缘，工具类项目有可能在用，大项目敢用么？并不敢。人家用nodejs就用了他的长处，并发性能想对PHP，java高，渲染层模板可以由前端一手搞定，减少了原来前后端的沟通成本，人家很清楚nodejs并不适合做复杂的业务逻辑，不管是在稳定性还是编程难度上都不适合。这也是我预言一些现在用nodejs的公司成功后会搞混合语言框架的原因，大公司这么用，小公司变大了也不会差太多，nodejs也就能在创业公司过过全栈的瘾，大家到时候可以来打我的脸，我倒是希望我错了，一些人的全栈梦还是不要破的为好。国内用nodejs的公司有几个能对nodejs改进的？src，lib目录的源码看了没？libuv，http_parser浏览过没？我很难想想一个对自己使用工具都没有深入了解的人敢拍着胸脯说，自己使用的工具是最好的，也许是最好的，但有更高要求的时候，有几个人能改进的？人阿里java团队是顶尖的，jvm都玩得转，都没说出java一统天下的豪言，但就是一些连自己工具都没搞明白的人在灭这语言，那框架的，这不是很好笑么？当国内有团队能够对nodejs贡献大量源代码的时候，再来吹点牛逼，或许还像那么回事。

nodejs第三个适用的场景是前端工具链，我个人觉得这是nodejs现阶段最合适的应用场景，是真正能够提高前端生产效率的。

我总结起来，越是没有深入使用和研究的，越容易发展成脑残粉，也越把我这样的人当成黑子。有一定积累和经验的人，看到nodejs的感觉不应该是像发现新大陆一样，而是觉得自己多了个选择。在这些人眼里，大约就是会javascript，至于会到什么程度，那是未知数，反正nodejs是银蛋，nodejs助他一下子翻身了。大约知道nodejs的并发性能比PHP，java强，但nodejs兴起的这几年，新框架和语言层出不穷啊，go，fibjs，openresty，不管是性能还是编程模型都比nodejs强，还拿性能安慰就是典型的不知有汉，无论魏晋了。这也是我希望nodejs要改变的原因，nodejs的编程模型落后了，异步不能这么玩了，回调异步在复杂的业务逻辑面前就是个笑话，c，c++，java，python的回调异步无不说明了这个问题，编程太难了，大家以为nodejs成功了么？即便是借助javascript和v8的光环，现在nodejs的应用领域还是主要集中于业务逻辑不太复杂的应用上，比如创业项目，比如服务端渲染层，这么比较下来，nodejs的确进步了一点，但并没有一些人宣扬的可以灭了其他框架和语言。我还是那句话，nodejs不是银蛋，实际去做出个大项目来证明nodejs才是正途，而不是整天吹牛逼灭天灭地的。

nodejs刚出来的时候，为了追求性能，将所有异步操作都用回调来实现，到现在nodejs的v8绑定接口还是基于回调的，并发性能的确是高的，但要看跟谁比，跟PHP，java的确是没有问题，但跟后来的几个比，那数据就有点不太好看了。在落后的编程模型面前，又失去了性能优势，这样是要一统江湖恐怕是比较困难的。复杂的业务逻辑和回调异步的矛盾是无法调和的，解决的思路只有变回调异步为形式同步，ES6的generator/yield有了一点改变，ES7的async/await是前者的语法糖，本质上是一样的，只不过原来由co等库干的活，让编译器给干了，在最底层还是回调。有的人被回调异步折磨个半死，看到了ES6，宣称这就是异步的终极方案啊。

这绝对不是终极方案，能够让所有同步程序员享受异步好处的异步才是异步方案的终极，没有异步的异步才是异步的终极方案。

不管是ES6还是ES7，回调都要转换成promise，ES6回调的自动调用需要外部库的支持。这两种方案都存在显式异步的传染性问题，这种方案或许兼容过去回调代码可能好一些，但你只要引入一个异步过程，其他所有异步过程将不得不被async/await包装起来，如果你不小心忘记了，业务逻辑的顺序可能就会被搞乱。在性能上，引入一些外部同步包装肯定会在一定程度上损失纯回调带来的性能好处的，但nodejs的性能已经不乐观了，这点损失恐怕还是要在乎的。

我的方案是没有显式异步的，如果某些人担心显式异步无法和同步函数区分，那你大可以在异步函数上加个async前缀，标示一下就可以了，我的方案并不需要在外面做任何同步包装，我们要写的代码就是同步的，异步函数是直接返回结果，并不需要通过回调来取值，我是用c，lua，libuv实现的，利用lua的协程，在c层面将回调异步转换为lua层面的形式同步。如果我读一个文件，我直接在协程里像写同步程序一样写异步程序。

local fs = require('fs')

-- 如在服务端，每个连接会自动生成一个coroutine，不需要自建coroutine。
-- 单独使用时，异步操作必须被包裹在coroutine内。
-- 所有在coroutine内部的异步操作，无需像async/await那样传染性标记，其他库的异步操作只要被包裹在一个coroutine内部，都可以直接使用，而不需要额外再建coroutine来包装
local co = coroutine.create(function()
	local fd = fs.open('test.txt', 'w')
	local write_size = fs.write(fd, 'hello world')
	fs.close(fd)
	
	local data, err = fs.readFile('test.txt')
	print(err)
	print(data)
	fs.close(fd)
end)

coroutine.resume(co)

项目地址 https://github.com/coordcn/LuaIO 同类项目openresty更成熟点，我的还是个人项目，还在开发中，tcp模块已经完成，http模块会在春节后发布。

nodejs最不缺的是人，但最缺的也是人。

如果这波创业浪潮今年继续上扬的话，程序员价格还会上涨，这个过程中会有很多东郭先生进场。潮水过后，才会见分晓。马云创业碰上互联网冬天，公司要裁员，他在声称自己多么不忍的情况下还是砍了好多，一些还是慕名而来的投奔他的。由此可见，到了冬天，资本是多么的残忍。不管是公司，还是技术，过过冬天再说成功也不迟。nodejs生态或许不是问题，但现在的问题是，茫茫多的库，我如何选择是个大问题，不但是个大问题，还可能成为一门学问。。。所以个人愚见，一些要灭天灭地的兄弟，把前端搞精通了，再来搞后端也不迟，觉得自己技术有多牛逼了，可不能跟一些刚入门的比。前后端不是一门语言就能统一得了的，一枝独秀不是春，百花齐放春满园，都把别人整死了，没了竞争对手，自己也会失去前进的动力，各种语言和框架都有其存在的价值，尤其是一些发展了好多年的，真不是吹吹牛逼就能把人给灭了的。

中国有个星际争霸电子竞技选手叫罗贤，他有次在电视上做节目，在战网上随机找个人打，结果连续输了两把，最后一把，罗贤好不容易要赢了，结果对方发来消息说，不要以为你赢了，然后这个神族选手变出了一队大和，罗贤又输了。从此，不要以为你赢了就成了一个梗，你技术再好，哼哼，不要以为你赢了，我开挂。

借这句圈内名言，我想说：

不要以为你会javascript，你就会前端了。

不要以为你会javascript，你就会后端了。

不要以为你会javascript，你就会全栈了。

不要以为你会javascript，你就会nodejs了。

不要以为你会javascript，你就真的会javascript了。

不管是前端还是后端，语言层面的真正变革才是正途，如果javascript还像ES6这样，加好多语法糖，跟之前的坑不划清界线，不要说一统江湖，生存都可能受到威胁，说不定哪个语言开了外挂还找了干爹。

不要以为你赢了。。。