Koa / Co / Bluebird or Q / Generators / Promises /

摘要：经常游荡在的我总能发现许多好问题和好答案。尽管网络上有着各式各样的关于该主题的指导，但涉及到在各种情景下的最佳实践，或者较好实践的方面还是不够清晰。我寄希望于针对我这篇裹脚布式问题的回复可以改变这一现状。我感觉因此收益的绝对不止是我一个人。

  
经常游荡在 SO 的我总能发现许多好问题和好答案。它们的“好”不仅仅在于知识的价值，更可贵之处在于如何表达：如何“提问”／如何“回答”。不久前我在 SF 发了一篇 WebComponents 和 React 的对比 就是一个很典型的范例，今天我又发现看到这样的一篇，不敢独享，略做翻译继续奉献给诸位。（唯一的回答比较长还没翻译完且我也在等待更好的回答，等有时间会补充）

I"m investigating building a web app in part with Koa, but I don"t quite have a handle on the hows, whens, and whys of choosing between - and applying - the range of supportive "making async easier" technologies/approaches (listed below).
我正在为了创建 web 应用时和 Koa 有关的部分做调研，但我对于一系列“让异步编程更轻松”的技术／方法（下文列出），很难抉择如何、何时、以及为何选择且运用。

Overall the disparate guidance on the web about this subject still leaves things blurry, especially in respect to evolving best practices, or at least better ones, and under what scenarios. There seems to be little or nothing on the web that puts it all in context.
尽管网络上有着各式各样的关于该主题的指导，但涉及到在各种情景下的最佳实践，或者较好实践的方面还是不够清晰。看起来网上几乎没有“百科全书”。

I"m hoping the responses to this big arse sprawling post can correct that. Also maybe the questions below can inspire someone to write a thorough blog post or the like to address this matter. My sense is I"m not even close to the only one who would benefit from that.
我寄希望于针对我这篇“裹脚布”式问题的回复可以改变这一现状。同时也希望下面的问题可以激发某人写一篇博客或什么的将其囊括总结。我感觉因此收益的绝对不止是我一个人。

So I"d be pleased if the bright community could help answer and provide clarity to the following questions in respect to the technologies listed below (in bold type):
所以我很高兴若有人能从如下角度针对后面的问题（黑体）提供清楚的回答：

  
a) How, and under what circumstance (as applicable) are they complements, supplements, substitutes, and/or overlapping solutions to one another?

  a) 在何种（可适用的）情形下，它们相互之间可怎样补充、替换、并且／或者彼此重复？

  
b) What are their trade-offs in respect to speed-performance, error handling ease, and debugging ease?

  b) 在速度／性能，便于错误处理和便于调试这几方面，它们各自的利弊是什么？

  
c) When, where, and why may it be better to use "this" versus "that" technology, technologies-combo, and/or approach?

  c) 在何时，何处用“这个”代替“那个”技术／技术组合／方法会更好，以及原因为何？

  
d) Which technologies or approaches, if any, may be "dimming stars".

  d) 哪一种技术或方法，如果有的话，可能已经是“昨日黄花”。

Technologies:
技术：

Koa

My understanding:
我的理解：

Koa is a minimal foundation for build Node apps geared for taking advantage of ECMAScript-6 features, one feature in particular being generators.
Koa 是受益于 ES6特性，特别是 Generators 特性的用来开发 Node 应用的最小化基础框架。

Co

My understanding:
我的理解：

Co is a library of utilites for running ECMAScript-6 generators (which are native to Node .011 harmony), with the goal to allieve some/much(?) of the need to write boilerplate code for running and managing generators.
Co 是运行 ES6 Generators（Node .011 harmony 模式下原生支持）的工具类库，其目标是帮助编写部分／更多（？）的用于运行和管理 generators 的模版代码。

Co is intrinsically part of Koa(?).
Co 本质上是 Koa 的一部分（？）。

Specific questions:
针对性问题：

If and how does one use Co differently in Koa than in a non-Koa context. In other words, does Koa wholly facade Co?
能否且若能则如何让 Co 在非 Koa 的场合下以不同于 Koa 的方式使用？换言之，Koa 是否只是换了一个“马甲”的 Co？

Could Co be replaced in Koa with some other like generator library if there is/was a better one? Are there any?
在 Koa 当中有能代替 Co 的其他 generator 类库吗？

Promise Libraries such as "Q" and Bluebird

My understanding:
我的理解：

They are in a sense "polyfills" for implmententing the Promises/A+ spec, if and until Node natively runs that spec.
它们都是 Promises/A+ 规范的 polyfills 实现，当且直到 Node 原生实现了该规范。

They have some further non-spec convenience utilities for facilitating the use promises, such as Bluebird"s promisfyAll utility.
它们实现了一些规范外的便利方法以便更好的使用 promises，比如 Bluebird 的 promisfyAll。

Specific questions:
针对性问题：

My understanding is the ECMAScript-6 spec does/will largely reflect the Promises/A+ spec, but even so, Node 0.11v harmony does not natively implement Promises. (Is this correct?) However when it does, will technologies such as Q and Bluebird be on their way out?
我理解中的 ES6 规范（将）会大量体现 Promises/A+ 规范，可即便如此，Node 0.11v harmony 没有原生 Promises 实现（对吗？）。若将来实现了，像 Q 和 Bluebird 这样的技术是不是就要过时了？

I"ve read something to the effect that "Q" and Bluebird support generators. What does this mean? Does it mean in part that, for example, they to some degree provided the same utility as Co, and if so to what degree?
我读到过一些东西说 Q 和 Bluebird 支持 generators。这是什么意思？是不是意味着在某种程度上它们提供了和 Co 一样的功能？如果是的化，一样到了何种程度？

Thunks and Promises
（译注：此二者皆为术语不做翻译更佳）

I think I have an fair handle on what they are, but hoping someone can provide a succinct and clear "elevator pitch" definition on what each is, and of course, as asked above, to explain when to use one versus the other -- in a Koa context and not in it.
我想我对此二者已经理解了，不过还是希望有谁能提供一个简明扼要的“电梯推介”（译注：即在做个电梯的时间里，如一分钟内，说清楚一个概念），且能解释下二者的对比——在使用和不使用 Koa 的情形下。

Specific questions:
针对性问题：

Pro and cons to using something like Bluebird"s promisfy, versus say using Thunkify (github com/visionmedia/node-thunkify)?
对比使用 Bluebird 等 promise 式的库和 thunk 式的库（如 https://github.com/visionmedia/node-thunkify）之间的优点和缺点

To give some further context to this post and its questions, it might be interesting if Koa techniques presented in the following webpages could be discussed and contrasted (especiallly on a pros vs cons basis):
为了对本问题提供更多的背景资料，下列涉及 Koa 技术的资料若能一并加以探讨和对比（特别是优劣比较）那就再好不过了：

a) http://www.marcusoft.net/2014/03/koaintro.html (Where"s the thunks or promises, or am I not seeing something?)

b) https://strongloop.com/strongblog/node-js-express-introduction-koa-js-... (Again, where"s the thunks or promises?)

c) http://github.com/koajs/koa/blob/master/docs/guide.md (What does the "next" argument equate to, and what set it and where?)

d) http://blog.peterdecroos.com/blog/2014/01/22/javascript-generators-fir... (Not in a Koa context, but presents the use of Co with a promise library (Bluebird), so I"m assuming the technique/pattern presented here lends itself to usage in Koa(?). If so, then how well?

Thanks all!