async好像比较简单易用, q相比有哪些优势呢?
回复 (17)
F
都不好 还是Generator好 拥抱koa吧
R
已经搞懂Promise的话，Async跟Q也就不到半天的学习成本吧
E
我觉得还是看自己使用习惯，喜欢哪个用哪个就得了，程序不是限制我们，而是方便我们
C
没用过Q，用过angular的$q，不知道是不是一样。用过一下async，感觉不是很强大。
J
引用 coolicer没用过Q，用过angular的$q，不知道是不是一样。用过一下async，感觉不是很强大。
正纠结用async还是q... q比较强大?
R
个人觉得能用就可以
A
都是基于回调的方式。 q基于promise模式，个人感觉做错误处理时候比较清晰，不过有一定学习成本
J
引用 racyily个人觉得能用就可以
用q试一试先...
J
引用 allenzhong都是基于回调的方式。 q基于promise模式，个人感觉做错误处理时候比较清晰，不过有一定学习成本
promise模式, 很高深的样子啊!
A
引用 allenzhong都是基于回调的方式。 q基于promise模式，个人感觉做错误处理时候比较清晰，不过有一定学习成本
@jeffZhong 不高深，参看朴灵的书里面有讲还有他自己的实现，或者自行google下，网上很多
S
Y
async，谢谢，用了很久了
Y
其实这是两个东西..没有选择谁和谁的问题.
如果喜欢回调 用async 如果喜欢promise(同步的风格,写异步的代码) 用Q 或者 https://github.com/petkaantonov/bluebird 这个性能应该比Q给力...
D
没必要纠结在这种东西上，就是一些简单流程控制回避嵌套回调
A
如果只是做异步调用，都不要选，用bluebird，性能超过q/async很多，也有promisify函数可以很方便的转换常规的函数，用起来非常不错 不过async还自带很多比较特殊的功能，比如queue，cargo等等，q还可以搭配qx等等做其他的
J
现在在使用Q.js, q不方便的地方就是要将用到的函数 promise化, 一般的函数用自带的denodeify就可以转化了, 复杂一点的要自定义写deffer ,promise, 多数情况下,觉得还是用async比较舒服啊
参与回复
登录后即可参与回复。登录