我不喜欢老赵的wind.js那样的，用编译的方式来达到异步，在js中，就应该尽量用异步的思想去思考问题。而eventproxy的接口太繁琐，完全可以用链式表达式将各个异步操作的依赖关系表示清楚。

@jeffz 相反，我觉得将思维从同步方式转换到异步方式才是进化。对于并发的处理，恰恰是同步方式的弱项而是异步的强项。很多人认为异步会把事情搞砸，将逻辑搞乱，我认为不是异步的问题，而是缺少一种适用异步的描述方式，在这一点我深受[Step]启发（我认为其唯一的缺陷是不应将异常传递下去），但力求更好。 [step]:http://github.com/creationix/step

看github上的源代码吧，应该不是很难理解。

@jeffz 在我看来从同步思维转向异步思维才是进化（针对您的幻灯片中的观点）。因此我并没有进化，而是node.js相对于其他很多语言来说进化了。而我所带来的仅仅是流程控制库更好的易用性，和更好的错误处理。在我的理解来看，wind.js就是让程序员用同步的方式编写能够异步执行的库，这个理解偏差不会太远吧？或许对于刚从其他语言转来的程序员、迁移现有的项目等有所帮助，但我认为要更好的使用node.js，则应该改造自己思维。我的库面向的也是完成了这些转变的程序员。

@thynson 刚才网页没响应了，一下n连发

var Step = require('step');
var con = require('console');

Step(
    function() {
        var next1 = this.parallel();
        var next2 = this.parallel();
        setTimeout(function() {
            next1({ error : 1}, 5);
        }, 100);
        setTimeout(function() {
            next2({ error : 2}, 20);
        }, 200);
    },
    function(err, a, b) {
        con.log(err);
        con.log(a);
        con.log(b);
    }
)

第一个异常{error : 1 }会被覆盖掉.

var xchain = require('xchain');
var con = require('console');

xchain(
  function(next) {
    setTimeout(function() {
      next({error : 1}); //异步调用中异常，不能用throw
    }, 100);
  }, 
  function(next) {
    next({error : 2});// 等价于 throw {error : 2};
  },
  function(next) {
    throw {error : 3};//等价于 next({error : 3});
  }
)(
  function(next) {
    
  }
).run(function(err, next) {
  con.log(err);
  next();
});

传给run方法的回调针对不同的异常会被调用三次

async.reduce和这个不是一个东西。 async.waterfall是完全串行的，目的也和xchain不一样，只有async.auto才有可比性。

可以@danielking。

@jeffz 首先此非迎合工具，但是如果不适合于自己，为何不换一个工具？在你我看来同一个工具的价值不同，各取所需便是。 其次，对于一些人来说，强制的异步是一种限制，但对我和另一些人来说，这反而是其苦苦追寻的东西。

@jeffz 好吧，我所需要的正是这种“闭包+匿名函数”来驱动的异步，想必您没有接触过函数式编程语言，对于Lisp，Scala，Erlang等语言的用户而言，“闭包和匿名函数”可是思考问题的基石。既然视角不同，多说无益，但还请你承认，js首先是一门函数式编程语言。

@jeffz 好吧，这么说是我的逻辑错误（连带地把js也归为非函数式编程语言）；Wind.js的实现也确实少不了函数式编程的理论，在评价前未调研也是因为我的偏见。 既然如此，那我就不带偏见的论述： 为什么我说“回调式的异步是我一直苦苦追寻的”，因为从我的经验来说，回调式的异步更有扩展性，你可以传入多个回调，而这些回调可以毫无关系，分散在工程各处；但函数返回值只有一处能够得到（除非把返回值再传给一组回调）。之所以我坚持回调式异步优越先进，正是因为这一点，一个是新代码调用旧代码，一个是就代码调用新代码，两者扩展性可见一斑，不知你是否承认，还是说wind.js将要解决这一点？ 以上不论async，step，xchain以及wind.js如何，只是针对回调风格的和返回值风格而言。 总之，与其花精力和代价（破坏了代码的简洁，受制于eval的外围闭包而不能简化）来得到串行的异步框架，还不如花在研究如何让回调式的异步更符合直觉的框架。尽管后者在理解起来或许比串行的好难，但是需求发生变动的时候，后者更敏捷。

@jeffz 我当然用过，每一次编译一个函数要套上eval等好几个东西，冗余东西太多了，当然这不是大问题。嘛，其实也没什么好争的。你要说我偏执于回调也没错，js这种回调如此廉价的语言不用回调太可惜了。

@151263 我之所以写xchain就是因为曾经写了个嵌套七八层的网页脚本，当时还不知道async和step。async，step以及我的xchain，目的都是把嵌套的回调平铺开来。至于每一秒一个循环，js的正解就是setTimeout或者setInterval。用js就应该Think in async way，不要纠结不能阻塞在控制流当中。

@151263 递归没什么不对，递归的表达能力要比循环强很多。这不是我的观点，你可以去问问玩lisp及其方言的那些人，当然这需要思维的转变。

@jeffz lua我不评论。而generator其实是高阶函数的语法糖，并没有真正改变什么。

@jeffz 比如拿高阶函数简单的模仿python的xrange就是这样

function xrange(n) {
    var i = 0;
    return function() {
        if (i < n) return i++;
        else return undefined;
    }
}

yield不过是把隐式创建了闭包保存状态（或者其他途径），没有yield，高阶函数也能做到。你认为我这是信口开河么？说实话，你既然能写出wind.js，我觉得你应该很容易看出这一点。 至于递归，有时候在描述解决思路上，要比直接的循环要好，大部分算法以及概念难道不是以递归来描述的？扯远了。

@jeffz 再咬文嚼字一下，大部分算法->许多算法。当然我也没有说循环一无是处。