摘要：經常游蕩在的我總能發現許多好問題和好答案。盡管網絡上有著各式各樣的關于該主題的指導，但涉及到在各種情景下的最佳實踐，或者較好實踐的方面還是不夠清晰。我寄希望于針對我這篇裹腳布式問題的回復可以改變這一現狀。我感覺因此收益的絕對不止是我一個人。

  
經常游蕩在 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!