Hexo: [feature request] Consideration of using async / await

[segayuu]

For feature request

The native promise after node v10 is fast enough.
Since async / await is supported in node v7 or later, it can be used when support of node v6 LTS (maintenance) is turned off.
Using async / await tends to make the code simple, and sequential asynchronous is faster than bluebird on the bluebird side benchmark (in the case of parallel, now bluebird is faster).

[NoahDragon]

Agree. Performance is always the key improvement for Hexo. IMHO, this is not a feature, more like an enhancement. Anyway, thanks for bringing this up.

[YoshinoriN]

I agree. Same as other hexo repositories.
IMO we can drop node v6 support after 2019 Apr.

[curbengh]

Just started working on this. A few observations:

• Bluebird.asCallback is to support callback style. Most Some Hexo API supports callback, so this can't be dropped for a foreseeable future.
• Promise.finally is only supported in Node 10.3+, so need to wait until Node 8 is dropped.

[SukkaW]

https://blog.kuzzle.io/bluebird-vs-native-vs-async/await-state-of-promises-performances-in-2019

TL;DR:
In Node.js 10, it is impossible to do without Bluebird in critical code areas given the performance of its promises compared to native promises and async/await.
In Node.js 12, the performance of async/await is comparable to that of Bluebird, so we can use async/await throughout Kuzzle core.

And according to the hexo's benchmark from some related PR, currently I see no performance gained through replacing bluebird with async / await.

[curbengh]

The benchmark linked by OP only shows async/await being slightly faster than bluebird (in sequential), the difference looks to be within margin of error.

I still believe bluebird is faster currently and for a foreseeable future; even our benchmark doesn't show it's faster in Node 13. Perhaps there may be bottleneck somewhere that either approach (bluebird/native) doesn't make any difference.

At the same time, async/await is significantly more readable, so if the perf is not affected, let's use it. especially for unit tests, where perf doesn't matter much.

[dailyrandomphoto]

* [`Bluebird.asCallback`] is to support callback style. Most Hexo API supports callback, so this can't be dropped for a foreseeable future.

How about deprecating asCallback in the internal APIs first? Without asCallback, the code will be more readable and simple.

- View.prototype.render = function(options, callback) {
+ View.prototype.render = function(options) {
- if (!callback && typeof options === 'function') {
-    callback = options;
-    options = {};
-  }

  options = options || {};

And I found only a few examples of using callbacks as asynchronous at https://hexo.io/api/.
Maybe we can drop all asCallback at the next major release.

[SukkaW]

https://blog.kuzzle.io/bluebird-vs-native-vs-async/await-state-of-promises-performances-in-2019

TL;DR:
In Node.js 10, it is impossible to do without Bluebird in critical code areas given the performance of its promises compared to native promises and async/await.
In Node.js 12, the performance of async/await is comparable to that of Bluebird, so we can use async/await throughout Kuzzle core.

And according to the hexo's benchmark from some related PR, currently I see no performance gained through replacing bluebird with async / await.

Here we are, 2020's benchmark: https://blog.kuzzle.io/bluebird-native-async_await-javascript-promises-performances-2020

Performance of sequential promises

Performance of parallel promises

Also, there goes the interesting discussion: https://github.com/nodejs/node/issues/33384

---

TL, DR

Bluebird appears to be consistently faster.