@fengmk2 相对流行是一方面，好坏又是另一方面，微软xp那么流行，你能说他很好？

node的好是相对PHP，java的同步代码而言的，是相对的好。node主体采用单线程回调异步模式，部分采用了线程池，文件系统，dns.lookup（）都是采用了线程池实现的。在关键的网络通信上，node是异步的，所以在通信效率上，node就相对比同步代码效率好。java也有异步接口，但是java不像javascript这样回调函数可以比较简单自然的实现，c也可以，c也存在同样的问题。node这种模式曾经是比较先进的。

node跟nginx比在某些方面又相对不好， 尤其在静态文件处理上，node用的是线程池模拟的异步，nginx则针对不同的文件类型提供了不同的策略，对大量的小文件，直接使用同步的系统调用sendfile，对大文件，使用AIO。而nginx也有自己不擅长的，处理动态的没有node方便，虽然有openresty，但从实际使用中来看，还是没有node方便。

曾经相对先进的回调模式下的异步现在也遇到了挑战者，那就是协程（coroutine），或者叫纤程（fiber），不管叫什么名字，他们本质上都是在用户空间模拟线程，这种线程是非常轻量的，调度完全由用户自己控制（或者用户不直接控制，而是由用户态程序控制）。这种模式有两大好处，一是避免了原生线程的大消耗，原生线程在一定程序上也能实现并行，也能实现异步，但他们的好处很快被线程的切换吞噬掉了。用户空间模拟的线程切换消耗就小得多。fibjs用的是自己实现的ucontext，lua用的是longjmp。解决了切换消耗，接下来就是锁，用户空间模拟的线程本质上是单线程的函数调用，只不过这种函数调用是可控的，没有了锁开销，性能上自然又获得了不少提升。即便是node使用的锁非常轻量，性能如果想再进一步，这也是实实在在的性能杀手。当然这不是node的问题，所有只要涉及多线程的，包括协程，都会面对这个问题。

协程相对原生的线程有很多好处，相对于回调有什么好处呢？首先，他们在异步编程领域的使命是一致的，那就是保证异步编程的执行顺序，回调山大家都不陌生，为什么会出现回调山呢？回调山就是保证异步过程是按照我们所设想的步骤去执行，在需要并行的地方，我可以将异步请求一股脑儿的都发出去，这个时候我对返回的顺序没有要求。在需要顺序执行的地方，我们则需要用一层套一层的回调来保证执行顺序。回调模式下的异步避免了多线程条件下，锁的竞争问题，编程模型跟多线程锁相比简化了，在思维上可以说更接近了人类思维模式。但是回调模式跟协程相比还是存在缺陷的，协程可以通过适当的处理，模拟出同步代码的效果，但本质上还是异步的，fibjs，openresty的代码都实现了这个效果。回调不行，回调是有传染性的，要获得异步的好处，所有异步代码必须全部用回调，某段逻辑上如果存在大量的异步过程，就需要大量的回调来应对，如果正好回调内部关联比较强烈，无法将回调拆分，那么写出的代码将是又长又难调试的，大家回想一下，自己是不是碰到过某些比较复杂的代码，是自己写的，过了一段时间后自己回过头来看，几乎都看不明白了，但是谢天谢地，那段代码还能运行，但是就不知道什么时候会出问题，这种担心大家有没有？有的话，那是正常的。javascript为了应对这个问题，加入了一些类似协程的东西，generator，async/await这些东西都发展的方向。现在的node还在发育，还远没到成熟的阶段，node的发展还是要看javascript的发展，现阶段promise和generator还是太麻烦，回调模式朝形式同步的进化路上还是有坑，这些问题我们都必须要面对，javascript与lua等天生具备协程能力的语言相比，在这场竞赛中谁能出头，最关键的是看javascript能不能迅速的顺应潮流，迅速的协程化，javascript已经在改变，就是步子太过婉约，他必须兼容过去的大量回调代码，但也必须要解决形式同步的问题。说这是生死问题，一点也不夸张，程序员会用脚投票，回调山真不是必须的。

@fengmk2 dns.lookup我本意并不是说它的性能问题，而是指出node实际上是使用线程的，不管是文件系统还是域名查询，线程的使用都是无奈的选择，因为没有更好的异步接口可用。

让各自做自己擅长的事情是正确的思维方式，可现实是很多人片面夸大了node的能力和好处，有意无意的回避了一些问题，看看现在这个论坛的质量就可以知道，有多少人是认真思考和调查过才投入node，当一些人没有真正思考调查过，以后再碰到一些坑，很自然的想法就是node不好，不如某某语言。事实上我们需要知道的是node优点在哪里？缺点在哪里？贪小便宜吃大亏，很多人都认为前后端统一了可以节省人力，但前后端真的一样么？前端的异步的调用能有几个？稍微复杂点的也就像sea.js，require.js等模块加载，其他的通讯跟后端不是可比的。如果一些人觉得可以统一的话，那只能说明一个问题，node所做的复杂度其实和前端相差不大，这样的确是可以统一的。这就回到了做自己擅长事情的问题上，node现阶段可以做什么，不可以做什么？我不清楚阿里怎么用的，用的深度，但是我认可大前端这种思维，node现阶段的使命就是这个，一个数据的管道。

你说的不错，语言没有最好的，只有最合适的，合适项目，合适自己。但要讲深入，这个概念太虚了，深入可以理解为能用node做一个中等规模的项目，碰到的坑自己能填满；也能理解为大体上理解了node，能够为node打打补丁；也能解释为完全理解了node，抛开能够自己实现一个。如果要讲深入，永远是没有尽头的。有的网友不是调侃《深入浅出》为《九浅一深》么？到了一定程度，深也就浅了，这是很自然的规律。

我不清楚你两年前的情况，我可以知道的是，es6刚刚开始普及，es7还在路上，我不知道你两年前是如何解决我提到的坑的。我不认为promise，generator/yield，async/await解决了问题，在我眼里只有形式同步才能真正解决问题。这里已经无需争论回调的问题了，回调好不好，看看javascript自己就明白了，回调要真好，就不会吸收这么多其他语言的特性了。说白了，node最大的不确定其实就是来自己于javascript本身，如果语言进化方向对了，皆大欢喜，一旦出了问题，比如c++，搞得复杂无比，javascript有没有这种趋势呢？我认为是有的。

你对回调和事件的看法，我建议你去认真看一看fibjs和openresty，回调和异步真的是两码事，事件只是碰巧来凑热闹而已。我本来对node是没有任何反思的，完全的脑残粉（很多人以为我质疑node是因为不会用，你们想错了，我绝对不是刚入门的吐槽，更不是宣扬什么PHP好），去年fibjs让我重新做了思考，fibjs的源码我大体看了，实现方式上我不认同，但思想上我认同的，而且我认为是比较先进的。openresty实现方式上我是认同的，但与nginx结合得太过紧密，不如node灵活。这两个项目都是中国人做的，可见中国人的创造力并不是一些人说的那么差，我们是有能力去做一些事情的，关键还是要打开心门，要敢于质疑一些现成的东西，现成的东西或许用得很舒服，但如果没有搞明白内部的原理，自己就很难有突破和超越。我对node的质疑完全不是心血来潮，而是有过仔细的调查，不管从javascript自身的发展，还是新出现的一些替代品来看，形式同步都是发展的方向。node并不是要被什么东西替代，而是要被新的思想替代。node将来可能还是node，只是不再有显式的异步而已。

我今天的预言可能大家都认为是笑话，是痴人说梦，请大家耐心一点，看两三年之后的是不是我说的，大家自然就会明白了。我做判断的基本原理就是我们所有的技术都是为了减少必要劳动，脑子能少转弯就少转弯，这里大部分高手，包括我自己，能够熟练运用回调，但我们不能放弃那些刚入门的兄弟，这些后备军就是生产力，或者node将来没有任何技巧，大家的工资会下降，但这就是趋势，谁也没办法改变，我们能够改变的唯有自己。形式同步的需求大家其实心里是明白的，只是不愿意说出来，那我就来做这个坏人，node只有突破了回调才能有更好的发展。近期只能用其他语言先替代一下，c+lua或许是一个不错的选择。

@fengmk2 如何才能沟通得来呢？node一统天下，web编程全包？这样违心的话我说不出来，而且我也没有node必亡的意思，我是希望node有变革，向好的方向发展，而且我也以javascript语言本身的进化做了说明，去回调不是你我能左右的，我的意思这么明白，这是难沟通？我只是强调，回调不是解决异步问题的唯一方法，不要把回调等同于异步，这个难沟通么？

难沟通的是心，而不是技术本身。

node社区必须要勇敢的面对自身的问题，才能更好的发展，javascript语言都在变，都在去回调，我们有什么理由无视呢？曾经回调是优势，但如果被回调束缚住，优势也会变劣势。诺基亚，微软，无不说明了这个道理，当独霸天下的时候，自以为就没了对手，技术上就保守了，最后市场就给了颜色。中国近代为什么落后，原来我们领先那么多，东方在欧洲人眼里就是天堂，东方的财富激发他们奋不顾身的大航海，我们在别人奋发的时候却停滞不前了，做起了天朝上国的美梦，我们没有资格去批判我们的祖先，这是人性使然，但我们必须警醒。

node即便不变革，三年时间还是可以撑的，别的技术从出生到成熟，没有个三五年都显得太稚嫩了，node这方面是优势，但过去的所有一切也都可能成为包袱。沟通真的很难么？用心了就不难，看看别人的实现，对比一下，我觉得没有什么难的。