@haozhang 读读这篇，或许会有帮助你理解 promise： https://github.com/ysmood/yaku/blob/master/docs/lazyTree.md

然后打个硬广 https://github.com/ysmood/yaku
这个库的异常处理机制在业界应该是最前沿的之一，对初学者会很友好。

@otakustay race 和 all 的实现都不完全正确，或者不符合 ES6 的规范。数组的每个 item 可以不是 promise 的，应该用 resolve wrap 起来，比如 race 的例子：

Promise.race = (arr) => new Promise((resolve, reject) => arr.forEach((v) => Promise.resolve(v).then(resolve, reject)));

另外不要忘记判断 arr 是否是 iterable 类型。虽然有点吹毛求疵了 XD

@Niphor 试试 NoFlow 吧，支持全部这些，且更简洁灵活，更能应对复杂的异步问题： https://github.com/ysmood/noflow

复杂 route 的示例： https://github.com/ysmood/noflow/blob/master/examples/routes.js

@love 你为啥要说“二个语言级异步转同步方案”呢？这个说法就不对啊，为什么 yield 就被对号入座了呢？这个官方有推荐这种用法吗？ES 的作者们都没这么说。只是有些人比如 TJ， hack 了一下 yield 的一种特性而已，而且被很多一知半解的人宣传的变了味道。

换个说法，我能用 swich case 完成全部的 yield 的功能，那是不是说 switch case 能算第三种 异步语法了呢？很多方法都是能简化异步问题的，哪止一两种，即使是 callback，不谈 js，即使在 C 编程刚流行这个概念的时候也是解决很多棘手的异步问题的，只不过随着时间的推移需求变得更复杂了，人们又开始寻找能解决当下问题的工具而已。

我敢说用不了几年当 async await 被大量使用后，人们能解决更多更复杂问题的时候又会有新的语法被发明出来。不说未来，即使是现在就有很多玩转了 yield async await promise 开始抱怨它们的总总问题了。有兴趣的话，可以去 MDN 订阅个 mailing list 看看业内人士们是如何讨论未来的，最近两天就有几个哥们一直在讨论 async 的各种问题。

@gkuchan 随时欢迎，可以加我 Telegram，用户名是 Yad Smood。其他的 IM 也行，比如 G+ 什么的。

事实上这个项目已经在公司内部的一些项目里用上了，个人感觉除了做 http server，做代理服务也比 express 或 koa 便利很多。我通常需要的是一些小而美的东西。

这个项目实际上一开始只是我另一个叫 nokit 项目的一个子函数，我最近觉得它非常有意义，于是打算单独抽离出来立项了。

关于 TODO，我的主要原始代码是用 coffeescript 写的，最近打算将 coffee 翻译成 js。
另外就是单测和 example 覆盖率太低，现在就只是写了些基础的测试和例子。尤其是例子，还不能充分表达这种编程方式的妙处。

@Numbcoder 用 babel 的话可以 ES7 await，具体你看这个项目的 readme

@coolicer 一开始就在 FAQ 里说了名字的问题，就是怕这样的吐槽，这名字其实就是 promise 的意思，只是换了一个语言而已，否则取名字太困难了，好的名字都被别人抢了。

@lwege 了解了，可以加到扩展里去，但基础库不会有这个功能。当时我就是被 bluebird error 的这层 wrap 恶心到过，才想自己写个库的，它这么干会和原生写法不兼容。

要扩展加个 xcatch 之类的就行了，比如你 new error 的时候，用库提供的些标准 error 类型，这时就能用 xcatch 到指定 type 的 error。

关于 lodash 模块话 API 这个确实可以做，多谢提醒～

@iwege 对 catch 已经有所加强了，但还有很多可优化空间，之后有时间会进一步加强。helper 这个我不是很理解，能具体解释下吗？

@coolicer 我读过 babeljs 用的 core-js 来实现 Promise，这个实现很大，我刚测了最新的 babel，编译之后 minify 了也有 20KB，太大了，而且也不支持 unhandled rejection 和 long stack trace。性能也没看到有太多优化:

Node v1.8.1
OS darwin
Arch x64
CPU Intel(R) Core(TM) i7-4770HQ CPU @ 2.20GHz
--------------------------------------------------------------------------------
yaku
total: 234ms
init: 155ms
resolution: 79ms
memory: rss - 115mb | heapTotal - 96mb | heapUsed - 76mb
babel-runtime
total: 770ms
init: 527ms
resolution: 243ms
memory: rss - 190mb | heapTotal - 172mb | heapUsed - 150mb

比 yaku 慢了接近 3 倍

@coolicer 但当下并不是所有浏览器都实现了ES6

@otakustay 我不打算入 aplus-test 的坑了，我另有计划，我打算把 Bluebird 的 test suite 抽离出来，它的单测应该是业界比较可信的，是实践的结果。

@otakustay 抱歉，话说的可能重了点，就是论事而已。

题外话，可以试着自动生成文档。打个硬广吧，可以用我写的 nokit 自动生成文档，yaku就是用它生成的 readme。好玩的是 nokit 也依赖了 yaku。nokit 这个用于替代 gulp，更好用。看看 yaku 怎么用 nokit 的就行了。

@otakustay 我这个库就在你厂的一些项目跑着呢。我 readme 第一句话就是说比原生的快，这就是 node 使用它的理由。比如此时此刻你厂用的一个门户级网站就是就是用的 node 0.8，你部门不代表你厂，不代表现实复杂世界吧？

抱歉 @laoyur 君，@错对象了，之前都是 @otakustay 才对。

@laoyur 而且类似这种单测也和原生 Promise 都不一致：

new Promise(function () { throw 10 }).catch(function() {})

其实不是把 promises-aplus-tests 都跑过就万事大吉了，还是有很多浏览器的规范在里面的。

@laoyur 你这个在 node 下已经慢到跟 q（2755ms） 差不多了，Bluebird 最快 301ms，上面的测试越小越快。

@laoyur 除了 shim 外的功能应该基于一个基础库开发。比如我会把 yaku 写到完善，然后基于它写个 yaku-ex 之类的，人们可以选择最适合需求的，而不是一股脑都放一起。

关于类似 finally 这种我很早就在 stackoverflow 上讨论过了，ES6 大概不会支持的见: http://stackoverflow.com/questions/26667598/will-javascript-es6-promise-support-done-api

你可以很容易在类似 yaku-ex 这样的库里实现一个。

@laoyur 所以这里为了问题的简化，只讨论 ES6，unhandled reject 这个我口误，是要符合现行 chrome 或者 firefox的处理方式，他们会在 gc 里处理它，我这边尽量模拟了这个过程，这很关键。

关于性能，我帮你跑了下，在 node 下差距很大：

Node v1.8.1
OS darwin
Arch x64
CPU Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
--------------------------------------------------------------------------------
yaku
total: 324ms
init: 215ms
resolution: 109ms
memory: rss - 115mb | heapTotal - 96mb | heapUsed - 76mb

pp
total: 2378ms
init: 1940ms
resolution: 438ms
memory: rss - 300mb | heapTotal - 278mb | heapUsed - 252mb

浏览器里没必要测性能，只有服务端 server 用 yaku 的时候这才是瓶颈，用户的 browser 里不可能跑重运算的。