Next.js: async generator vs syntax transform

[sedubois]

I don't know much about these things, but was wondering if there's a reason to prefer async generator/regenerator vs. something like fast-async which _claims_ to be 3-4 times faster?

[timneutkens]

Interesting. I'll benchmark changing this.

[timneutkens]

Apparently fast-async doesn't support calling await on normal functions that don't return a Promise. So if you, for example make a component which has a static getInitialProps instead of static async getInitialProps it will fail. Also, we have to drop the es2015 preset to implement fast-async, since it conflicts with babel-plugin-transform-runtime 😢 Also looked into kneden but that one is unmaintained from the looks of it.

[timneutkens]

If there is something else we can look into please let me know 👍 😄

[sedubois]

Thanks for looking that up. Would be good to give the feedback over there

[sedubois]

@timneutkens I opened an issue over there and there are suggestions on how to fix your concerns: https://github.com/MatAtBread/fast-async/issues/32#issuecomment-276014312

[TooTallNate]

So if you, for example make a component which has a static getInitialProps instead of static async getInitialProps it will fail.

To implement this properly we just need to wrap the getInitialProps return value with Promise.resolve(). (something like await Promise.resolve(this.getInitialProps())). It seems weird to me to rely on the parser for that behavior.

[timneutkens]

@TooTallNate Fair point. Will have a look into that 👍

[timneutkens]

Going to close this as the fast-async functionality seems to be going to go into babel 7, which we use now for Next.js.