Koa / Co / Bluebird or Q / Generators / Promises / Thunks 的相互关系

常常浪荡在 SO 的我总能发明很多好题目亲睦答案。它们的“好”不仅仅在于学问的代价,更难得的地方在于如何表达:如何“发问”/如何“回复”。不久前我在 SF 发了一篇 WebComponents 和 React 的对照 就是一个很典范的类型,本日我又发明看到如许的一篇,不敢独享,略做翻译继承奉献给诸位。(唯一的回复比较长还没翻译完且我也在守候更好的回复,等有时间会补充)

Koa / Co / Bluebird or Q / Generators / Promises / Thunks interplay? (Node.js)

Koa / Co / Bluebird or Q / Generators / Promises / Thunks 的相互关系(影响/作用)?

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 手艺的材料若能一并加以讨论和对照(特别是好坏比较)那就再好不过了:

Thanks all!

    原文作者:n͛i͛g͛h͛t͛i͛r͛e͛
    原文地址: https://segmentfault.com/a/1190000002678673
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞