我正在研究与Koa一起构建一个Web应用程序，但是我还没有完全了解Hows，whens以及为什么选择 - 并应用 - 支持“使异步更容易”的技术/方法（下面列出） .
总体而言，关于此主题的网络上的不同指南仍然使事情变得模糊，特别是在不断发展的最佳实践方面，或者至少是更好的方法，以及在什么情况下 . 在网络上似乎很少或根本没有把它全部放在上下文中 .
我希望对这个大屁股庞大的帖子做出回应可以纠正这个问题 . 也许下面的问题可以激发某人写一篇完整的博客文章等来解决这个问题 . 我的感觉是，我甚至没有接近唯一一个从中受益的人 .
因此，如果明亮的社区能够帮助回答并明确以下列出的技术（粗体字），我会很高兴：
- a）他们如何以及在何种情况下（如果适用）补充，补充，替代和/或重叠解决方案？ - b）在速度性能，错误处理容易性和调试简易性方面，他们的权衡是什么？ - c）何时，何地以及为什么使用“this”与“that”技术，技术组合和/或方法更好？ - d）哪些技术或方法（如果有的话）可能是“调光星” .
（希望可以很好地解释作为答案一部分的意见 . ）
==============================
技术：
*** Koa ***
我的理解：
Koa是构建节点应用程序的最小基础，旨在利用ECMAScript-6功能，其中一个特性是生成器 .
*** Co ***
我的理解：
- Co是一个用于运行ECMAScript-6生成器（它们是Node .011和谐的原生）的实用程序库，其目标是解决编写用于运行和管理生成器的样板代码的一些/多（？）需求 . - Co本质上是Koa（？）的一部分 .
具体问题：
- 如果以及如何在Koa中使用Co而不是在非Koa环境中使用Co.换句话说，Koa是完全立面Co吗？ - 如果有更好的产品库，Co可以用Koa替换其他类似的生成器库吗？有吗？
*** Promise Libraries such as "Q" and Bluebird ***
我的理解：
- 它们在某种意义上是“polyfill”用于实现Promises / A规范，如果Node直到运行该规范 . - 他们还有一些非规范的便利工具，用于促进使用承诺，例如Bluebird的promisfyAll实用程序 .
具体问题：
- 我的理解是ECMAScript-6规范确实/将在很大程度上反映Promises / A规范，但即便如此，Node 0.11v和声本身并不实现Promises . （这是正确的吗？）但是当它出现时，Q和Bluebird等技术是否正在逐步推出？ - 我读过“Q”和Bluebird支持生成器的内容 . 这是什么意思？例如，它在某种程度上是否意味着它们在某种程度上提供了与Co相同的效用，如果是这样，那么在多大程度上呢？
*** Thunks and Promises ***
我认为我对它们是什么有一个公平的处理，但希望有人可以提供一个简洁明了的“电梯间距”定义每个是什么，当然，如上所述，解释何时使用一个与另一个 - - 在Koa环境中而不是在它中 .
具体问题：
- 使用像Thunkify（github com / visionmedia / node-thunkify）使用像Bluebird这样的东西的赞成和利弊？
==============================
为了给这篇文章及其问题提供一些进一步的背景，如果可以对以下网页中提供的Koa技术进行讨论和对比（特别是在优点与缺点的基础上），这可能会很有趣：
- a）www.marcusoft . net / 2014/03 / koaintro.html（在哪里是thunk或promises，还是我没有看到什么？） - b）strongloop . com / strongblog / node-js-express-introduction-koa-js-zone（再次，thunk或promises在哪里？） - c）github . com / koajs / koa / blob / master / docs / guide.md（“下一个”参数等同于什么，设置它和在哪里？） - d）blog.peterdecroos . com / blog / 2014/01/22 / javascript-generators-first-impressions（不是在Koa上下文中，但是介绍了Co与promise库（Bluebird）的使用，所以我假设这里提供的技术/模式借出本身是用在Koa（？） . 如果是这样，那么有多好？
谢谢大家！
1 回答
我一直在工作现在广泛使用发电机一个月，所以也许我可以尝试一下 . 我会尽量将意见保持在最低限度 . 希望它有助于澄清一些混乱 .
缺乏最佳实践和更好解释的部分原因是该功能在javascript中仍然是如此新颖 . 仍然很少有地方可以使用生成器node.js和firefox是最突出的，虽然firefox偏离了标准 .
我想要注意的是，有一些像traceur和regenerator这样的工具可以让你使用它们进行开发，并允许你把它们变成半等效的ES5，所以如果你觉得使用它们很有乐趣，那么没有理由不开始使用它们除非你的目标是古老的浏览器 .
发电机
生成器最初并不被认为是处理异步控制流的一种方法，但它们可以很好地工作 . 生成器本质上是迭代器函数，允许通过使用yield来暂停和恢复它们的执行 .
yield关键字基本上表示返回此迭代的这个值，当我再次调用next（）时，我将从中断的位置开始 .
生成器函数是特殊函数，因为它们在第一次调用时不执行，而是返回一个迭代器对象，其上有几个方法，并且可以用于for-of循环和数组理解 .
send（）,:这将一个值发送到生成器，将其视为yield的最后一个值，并继续下一次迭代
next（）,:这将继续生成器的下一次迭代
throw（）：抛出异常INTO生成器，导致生成器抛出异常，就像它来自最后一个yield语句一样 .
close（）：这会强制生成器返回执行并调用生成器的任何finally代码，以便在需要时触发最终错误处理 .
他们暂停和恢复的能力使他们在管理流量控制方面如此强大 .
公司
Co围绕发电机的能力 Build ，使处理流量控制更容易 . 它不支持你可以用发生器做的所有事情，但是你可以通过它的使用来减少样板和头痛 . 出于流量控制的目的，我还没有发现我需要的东西已经超出了co提供的范围 . 虽然公平地说我没有尝试在流量控制期间向发电机发送值，但这确实带来了一些有趣的可能性......
还有其他的发电机库，其中一些我可以想到的是我的头顶暂停和发电机运行 . 我已经尝试过所有这些并且co提供了最大的灵活性 . 如果你还不习惯发电机，暂停可能会更容易一些，但我不能说有权威 .
至于节点和最佳实践，我认为co目前正在通过创建的大量支持工具赢得它们 . 暂停最有可能的亚军 .
Co使用promises和thunks并且它们用于yield语句，以便co知道何时继续执行生成器而不是手动调用next（） . Co还支持使用发电机，发电机功能，对象和阵列来进一步控制流量 .
通过生成数组或对象，您可以对所有生成的项执行并行操作 . 通过屈服于生成器或生成器函数，co将委托对新生成器的进一步调用，直到它完成，然后在当前生成器上继续调用next，允许您使用最少的样板代码有效地创建非常有趣的流控制机制 .
承诺
虽然我说我会将意见保持在最低限度但我想说明，对我而言，承诺可能是最难掌握的概念 . 它们是维护代码的强大工具，但它们很难掌握内部工作原理，如果用于高级流控制，可能会遇到很多问题 .
我能想到解释promises的最简单方法是它们是一个函数返回的对象，它维护函数的状态，以及在对象的特定状态被输入时调用的回调列表 .
承诺图书馆本身不会很快到达任何地方 . 他们为承诺包括done（）添加了很多很好的东西，这些承诺没有进入ES6规范 . 更不用说可以在浏览器和节点中使用相同的库我们将在很长一段时间内拥有它们 .
Thunks
Thunks只是一个函数，它接受一个参数回调并返回它们正在包装的另一个函数 .
这将创建一个闭包，允许调用代码实例化在其回调中传递的函数，以便在方法完成时告知它 .
在我看来，Thunks很容易理解和使用，但它们并不适合所有东西 . 例如，spawn是一个很大的痛苦来创造一个thunk，你可以做到，但这并不容易 .
Thunks vs. Promises
这些并不是相互排斥的，可以很容易地一起使用，但通常选择一个并坚持使用它会更好 . 或者至少选择一个约定，这样你就可以很容易地分辨出哪个 . 根据我的经验，thunk运行速度更快，但我还没有对它进行基准测试 . 大多数情况可能是因为它是一个较小的抽象，并没有内置的错误处理机制 .
你通常会构建一些需要错误处理的东西，所以根据你的代码，thunk的整体性能提升可以轻松地支持或支持promises .
何时使用
生成器 - 当你可以放心地说你的应用程序能够在最前端运行时，无论它是仅用于浏览器还是节点的firefox> 0.11.3
我一直在我现在所在的公司广泛使用它们，并且对控制流机制和它们允许的惰性评估感到高兴 .
Promises vs. Thunks - 这取决于你和你在每个人工作的舒适程度 . 他们没有提供相同的好处，也没有解决同样的问题 . Promises直接帮助处理异步问题，thunks只是确保函数获取其他代码传递所需的回调参数 .
您可以将它们一起使用，只要您可以保留它，以便明显哪个是您不会有问题的 .
使用生成器的Promises / Thunks - 我建议您在使用生成器进行控制流时随时执行此操作 . 这不是必要的，但更容易就像使用co作为控制流的抽象一样，生成器更容易 . 更少的代码输入，更容易的维护，以及更少的可能性，你将遇到其他人尚未遇到的边缘情况 .
Koa
我不打算详细介绍koa . 我只想说它类似于表达但写作利用发电机 . 这确实给它带来了一些独特的优势，例如更容易的错误处理和级联中间件 . 之前有很多方法可以完成所有这些任务，但它们并不优雅，有时也不是最高效的 .
特别提示：发电机打开了一扇我们尚未探索过的可能性之门 . 就像它们可以用于控制流程时那不是他们的初始设计我是肯定的，他们可以用来解决我们通常在javascript中遇到的许多其他问题 . 找到我们如何使用它们可能会比我更聪明，但我至少会开始玩它们并更好地了解它们的能力 . ES.next中的生成器还有更多好东西 .