Node.js 7.0预计在9月30日发布，支持async/await，Koa 2.x也将随之发布

666

赞，正在学 koa2

@ipfans 你说的是v8的完全stable版本，但不是node v7的。v7的due date确实是月底

新版koa-cli什么时候出

最关键的，v8没有动内核实现。这些语法糖都没用，要么v8自己实现多线程，由社区去实现一套协程机制，要么，就v8自己内核实现协程。没有协程，promise、co/yield、async/await都是鸡肋。我还是用function programming。(逃。。。

LTS遥遥无期啊 关键好多公司线上项目都是基于LTS版本做的 个人玩玩的话怎么都行 v8无法优化generator函数，目前只能手动写代码的时候注意一些了

事实上，按照 https://github.com/nodejs/node/issues/7904 和 https://www.chromium.org/developers/calendar 显示，大概到10月底才能stable版本发布，RC可能会在月底...

赞

大新闻啊

来自酷炫的 CNodeMD

是稳定版吗？

@falost 现在还确定不了

到时最看看koa2

感觉版本更新太快了，并不是好事。特别是对低版本无法兼容的情况下

不知道v8的async/await和co比效率怎么样，不过要等LTS还远着呢

来自酷炫的 CNodeMD

@iyuq 嗯，才第一个版本

@tanket node向后兼容做的还是非常好的，核心api都没问题的

干巴得～

async ！

https://github.com/nodejs/LTS#lts_schedule

暂时还没跳票过，应该还是准的

@i5ting

如果async和await落地了，性能是个什么情况？

因为我现在为了性能，都是使用Bluebrid来替代原生的Promsie的

http://bluebirdjs.com/docs/benchmarks.html

赞赞赞

@CoderIvan await落地了，你也还是需要promise的，我估计还是要用bb

@i5ting

哦，对喔，犯傻了，async和await替代的是Bluebrid.coroutine()和co()这些封装

总算是快出来了。。可以愉快的koa2了:)

更新真快啊

@kurten 异步转同步协程是绕不过去的，这么多评论就看到一个明白人。

有了内核协程，promise，async/await都不再需要，直接写同步代码就得了。

@coordcn 让程序员写得舒服，代码更短更可读就是语法糖的意义啊。性能不是唯一衡量标准

哈哈哈，不错不错

@timqian

这跟性能没关系（引入协程跟回调相比性能是降低的），你估计也不能理解为什么 @kurten 希望v8内部实现协程，你理解了就会明白，这些语法糖是完全没有意义的。

你可以用同步代码编写异步程序的时候，还要那些语法糖做什么？建议你去看下fibjs，openresty，开阔下眼界。

没有对比，就没有伤害。。。

希望 nodejs在有了await 后 能彻底击败 PHP， 在web api 这块统一语言， 然后go，scala等彻底变成特定领域语言。 现在做web 的语言和框架太多了， 重复劳动太多。

@jinwyp 你想多了吧，现在node只是在大前端比较火，web api这一块用node的并不多

@iyuq api层用node是合适的，希望这个地方可以放大，但就服务而言，可能go和java会更好。未来是各种语言一起用，而非单一某种，已经过了单打独斗的年代了

@i5ting 哈哈，我现在公司就是API也是用node做的

来自酷炫的 CNodeMD

@iyuq 这层用node性能足够，而且可前可后，是前后端分界最好的选择

@coldraincn 大开眼界

不着急，反正都用上了...语法层面各种折腾，就是为了好用点，更关注于业务实现...有时候因为一门语言高级特性的掌握而生出优越感...这是病

技术的选型真是个头痛的事情，我们目前Api用的都是nodejs，可是真心感觉业务层，数据层真不适合用nodejs。后面越来越感觉node的位置比较尴尬。上也不是下也不是。

@coordcn Meteor的后端HTTP模块的方法调用中，有个设计是如果提供了callback方法，就是异步写法，如果不传callback，就利用node-fibers把异步变成同步，这种设计我感觉可以迎合很多开发者的喜好了，纯同步代码有时候可能也不是必须的

@arden node.js操作数据库并不慢啊，如果你说不完善我倒是很认同。可能我们理解的api不一样

api -> db

我理解的是下面这种

api -> 服务（java、go、node按服务特点选） -> db

@alonprince 哇，看看去

@alonprince

那个fiber局限性太大了，还是看fibjs和openresty的实现吧，这两者在动态语言层面已经实现了完全同步，回调根本不会到动态语言接口中，nodejs必须要v8实现他们类似的协程，底层C++绑定接口还要大改动才行。

这个不是你感觉的问题，落后就是落后了，而且其他语言，如go也起来了，可选择的太多了。nodejs这种异步模式已经受限于javascript语言发展了，有的人不愿意听实话而已，自我安慰而已，这么发展下去的话，nodejs也就帮前端做做工具的命。

性能不再具有优势，或持平的情况下，编程模型就很关键了，况且nodejs性能已经落后了，nodejs唯一可以炫耀的或许只有生态，但生态是建立在编程模型和性能的基础上的，离开了基础，生态也是繁荣不起来的。

@i5ting api -> service(java、go) -> db 这个我认同。目前也在找方案，有没有合适的RPC方案？nodejs有个叫Seneca的微服务方案，但真心不喜欢直接用nodejs和db打交道。

@arden grpc可能最合适，跨语言，支持http2

@coordcn 这一点真心认同，nodejs目前就是生态好，各种库都有。但异步这个东西真心很恶心，必须的承认。不管以后直接支持了await也好，都不是一个好的解决方案。

@i5ting 谢谢，我去了解下。

@alonprince 其实我觉得还不如使用async/await或者promise+generator来的舒服。毕竟是原生支持！所有外来的东西，都是纸老虎。。。

@timqian 好，这话说的，来来来，让我们看看shit一样的v8实现的promise性能。。。 这里 把require('bluebird')这行注释掉跑跑看，你会过来深思一下你这句话的。。。

@coordcn 性能从来不是决定语言火不火的因素， 语言火不火主要看有没有用，实际上语言好不好用都不太重要， 现在web api 这块 就是php， nodejs， java的三分天下。 Go火的才莫名其妙，开发web api 对比php，和nodejs ，go根本没有优势。 GO目前应用只有docker，但和web api管关系不大

相比scala在大数据领域无可替代，Go现在根本没有杀手应用，docker目前只是一个部署工具，不用docker一样可以部署。 相反大数据不用scala没的选择。就像OC一样iOS没得选择，即使语言很啰嗦。 WEB API这块JAVA开发效率即使用spring boot 也很低了，未来还是PHP和NODEJS一争高下，在把ROR的东西都抄个精光后，世界上最好的语言和宇宙最好的语言一觉高低，由于有前端和NPM加成，未来javascript还是一统天下的节奏。性能不行在上特定语言都来得及。毕竟PHP7和NODEJS已经很快了

@jinwyp 我并不这么认为，go现在牛逼的应用和案例多的是了，并且越来越多，越来越火。如果是做跟Web页面相关的应用用php/nodejs合适。但如果只是做业务，包括api，go应该是最合适的。

9月30啦！ koa2发吗？

@dingyiming 坐等

坐等发布

坐等？ 自豪地采用 CNodeJS ionic

mark

坐等

看了下issue list，估计还要等上一个月

@i5ting due date和实际的release date是两个概念吧，一般都可能有一定的bugfix情况。理想是不会拖延，不过有可能发现新BUG原有bug修复时间过长之类的操作都有可能引起延期。现在情况应该是为了引入v8的稳定版要延期node v7？

@coordcn 我不清楚我是不是真的明白了你的意思，我猜想可不可能有这样一种情况，我只是想异步打一个日志或者写一个数据库，我没必要等到这个接口执行完成之后再执行剩下的代码，如果代码已经全同步书写之后，这种情况是不是就不太好解决了

@kurten 现在使用async/await的环境一点也不成熟，先不说用起来有多麻烦，相关配套也没完善，eslint到现在也没承认这个语法的正确性，每次写代码都不能通过eslint的验证，很早之前就看过@coordcn 说过的一句话，“回调就是为了确保同步执行的”，感觉就很对，很赞同coordcn的观点，但是纯同步代码又感觉不太灵活

然后 7.0到现在还是没有发？

然而并没有发

已经推迟到18号了

@rwing 貌似是October 25, 2016

@justjavac 你也要玩node了？

@i5ting 是吗 出处是？18号的消息我是从lts schdule里看到的。比较关注v7的发布时间 谢谢

@alonprince eslint为何不支持？可以用babel-eslint啊

@andyhu 我用的vscode，还不知道怎么把这个给弄成不报错的[手动滑稽]

@alonprince

你的考虑是正确的，但大部分情况下我们都是需要知道异步结果的，不关心异步结果只要忽略回调就行，这个协程也能做到的，但是需要增加额外的忽略回调的接口。协程引入性能上肯定没有纯粹的回调好，但回调大家用了这么长时间，编程模型不友好的问题是很突出的。所以ES6引入了一些类协程的特性，这些东西能缓解一部分回调的编程模型问题，但还是有代价的。至于纯协程代价大，还是类协程代价大，这个主要看实现。在目标上大家都是为了简化编程模型，这说明协程化这个方向是基本正确的。

协程天生就是解决并发的，在并发这块也没什么大问题，如果遇到并发请求，开几个协程一起请求，让出当前协程，等所有协程执行完成后，恢复当前协并返回结果。

协程本质上其实就是能够跨函数的高级goto。

其实这些东西都不是新东西，个人理解协程就是协作式多任务的一种吧，只有一个线程执行，除非自己的代码显式的出让执行权，或者隐式的出让（调用一些异步IO之类不会马上有结果的东东）执行权，其他代码才能执行。真想搞明白自己做个简单的协程试试也行（如果太闲或者太纠结的话）。

代码搞到最后就是为了自己感觉舒服，各种语言就像各种食物，吃肉吃青菜都要，只吃一种会出问题的：）

@alonprince 我也用vscode，没有问题，可以不报错

https://github.com/pauliusuza/node-v7-async-await-demo?utm_content=buffer9bce9&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

@fundon 没有安装成功啊，大晚上不好好睡觉，哈哈

10月25日，已经确定了7.x分支

https://github.com/nodejs/node/tree/v7.x

貌似nightly里已经有了8版本。。。。。

官网已经发布了

@rwing 我刚才看的时候还没有呢