如题
@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创业公司，创业部门肯定高于成熟公司和成熟部分，但吃螃蟹不是没有代价的，这中间的酸甜苦辣也只有他们自己知道了。
@coordcn 我本身就是C++/C开发出身的，担任过做过项目的兼职oracle 。DBA，也用过java的J2ee & ssh 也能写H5页面，粗通CSS，JS框架。就我本身而言，觉得nodejs 是非常做后端服务的，关键是要有好的策略，目前在一家新的小公司，勉强做系统设计和开发。nodejs 和python之间我考虑很久，还是nodejs 上马开发项目做互联网产品，全线nodejs，java 作为辅助（就是做运营数据报表）。觉得 linux /unix 和nodejs 环境下，开发真的很有效率，也很高效，舍弃java 是必然的。。。。本公司的java 开发者已经被我成功转化为nodejs开发者。。。都是做后端的，前端的andorid 暂时java必须。。。。 另外，我朋友的公司，他是系统总架构师，承接省级政府千万的项目，也是上马的nodejs和java并存。。。。。已经三年了。。。呵呵，他计划逐步在系统中替换掉java。。。。
后端每个人的理解概念是有很大差别的，我也没有要表达，node不适合做后端的意思，主要观点是谨慎，不要拿node当银弹。
nodejs和python之间要选择的话，我也会选择nodejs，因为我对python不了解。最关键的就是你的项目后端和你朋友项目的后端，这个到底后到哪个程度了，我比较关心这个问题，这个问题也关系到node的定位问题。省政府千万元还是千万并发？这个概念差远去了，你提到了是政府项目，这个项目对稳定性，安全有要求么？为什么不做纯node？而是要和java并存？这肯定是有原因的。
在我的概念里，node就是大前端，起浏览器与核心后端数据的桥接作用。
你们是怎么解决同步代码去写异步代码碰到的问题的？有没有一些好的经验，我个人的经验是，没有显式的异步才是最好的异步，所有需要显式变换的异步都是过渡方案。如果可以让你写同步代码，又能享受异步带来的性能好处，你还会选择node么？
个人觉得将技术选型脱离团队状况、业务场景等等来说是一点意义都没有的。 如果说楼主的所在的研发团队都是以Java为主，前端大家都可以写点代码，但是不熟练，而前端大牛就楼主一个，Node项目在楼主的努力下搞起来了。然后楼主离职了，这摊子谁来搞。没用Node前，大家都能写写代码，但是Node对于大部分后端来说完全就是很陌生啊。在这种情况下，楼主起码得做前期调研，内部培训，得保证有接班人，不至于楼主走了，项目也跟着完蛋。 再比如说业务单一简单，Java提供的restful接口也不必复用，用Jsp、Velocity绰绰有余，那我干嘛还多加一层Node，多了层转发就意味着性能的损耗，完全没必要啊。 最重要的一点，如果没有一个成熟的架构师来把控整个项目，注意了是整个项目，包括Java端和Node端，有人会说前后端分离，前端搞Node后端搞Java。绝对的前后端分离完全就是TM扯淡。两个项目的对接，接口的规定，权限的控制balabala一堆东西，如果项目初始没有规划好，后面你懂的。
没有最好，只有最合适！楼主慎重选择啊。
理性，中肯
稍稍提一下，中小项目这样是没有任何问题的，也都是一揽子框架里面啥都有，不过越做越大，就一定会拆成各种服务的，这个时候，存在java、node等等并存是非常有利的，微服务也是当下的一个潮流
我不是不赞同2位说法，而是希望其他新人对nodejs有足够的信心，未来是看好的
@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做复杂的业务，专心做大前端的活，这样的人又容易找了，价格还便宜，这就是个取舍的问题。
异步比同步性能高的前提是cpu大部分时间在空转，类似epoll比select性能高只在少数活动连接的情况下成立，如果所有链接都是活动连接，epoll和select性能是一样的 nodejs的高性能和开发迅速全是基于helloworld类型的应用前提下的，但实际上除了一些面子工程和玩具工程，真正赚钱的业务没有一个是类helloworld的 nodejs 虐人是带后劲的，越到后面劲道越大
nodejs起了个大早，现在跟其他后起的网络框架比却落后了，这其实跟很多人不能正视nodejs存在的问题有很大关系。
nodejs刚出来的时候，回调和协程之争，现在javascript语言本身发展路线证实了，到处回调是有危害的，要限制，要转换，如果这个问题在早几年被重视，也许javascript标准就不是现在这个不伦不类的样子，对异步转同步就会有更好的规划。node最根本的问题还是性能和编码难度的矛盾，性能现在已经没有优势了，编码难度虽然有改变，但核心还是没变。性能上没有优势，现在很多人又拿javascript的群众基础和库的数量安慰自己，这个会javascript和会写后端代码区别大去了，库数量巨大，真正有用，真正敢用的也就那几个。
node即便要用，也最好用在合适的地方，那些鼓吹前后端通吃的，那是没有体验过 @yakczh 所说的虐人后劲。
感谢各位大牛的评价，每个技术的出现肯定有其原因。也不会有一个技术能完成所有事情。如果你们是真心不喜欢nodejs，不用就是，没必要黑得那么给力。就去用你们喜欢的技术做事情吧，也不要太关注nodejs社区了，因为都是你们不喜欢的新闻和讨论，为什么这个不好的nodejs能这么吸引你们的关注呢？很少参与语言分歧的讨论，因为这跟每个人的口味一样，众口难调。希望大家还是回归各自喜欢的技术本身。这个帖还加精华，@alsotang 这样做不合适。 自豪地采用 CNodeJS ionic
@flyingcodes 那个项目的确是大量访问，做的是无线监控接入系统，无数终端接入，每隔一定时间就要访问的，就是2分钟－5分钟一次，各种图片，数据。。。等等。。。。数据访问密度很高啊。。。动态的接入。数据采集。 之所以java 是因为以前前期项目开始时期，还没有nodejs。。。。
一些人不知道什么心态？大家在这里讨论讨论，怎么就扣上帽子了？这里谁黑node了？明白黑什么意思么？真心没有黑node的意思，就是实话实说，有的人神经过敏了，说得不对指出来，大家讨论就是。
大家要明白一个道理，一个技术如果大家真心喜欢，即便有人黑，人还是会用。如果一些人老是神经过敏的，觉得人家提出一些node的弱点就是黑node，这是不是反而说明内心不太自信呢？node的问题，大家心里都清楚，就看愿不愿意说实话。这里面毕竟关系到一些人的利益。
node真好，就不要怕黑，自信点，况且也没人黑，别神经过敏，做技术心态很重要。
