Should we adopt async/await

[rahulreddy]

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Asynchronous/Async_await
https://developers.google.com/web/fundamentals/primers/async-functions
https://javascript.info/async-await

We didn't adopt when it was introduced as V8 implementation was not up to par in performance compared to callbacks as any other new features. Now that it performs the same and could bring cleaner way of writing our asynchronous methods, should we adopt it?
Performance indicators for V8 https://v8.dev/blog/fast-async

[miniscruff]

Yes. Async await is moving to be the standard across the board. JS is not the only one using this style as C#, python and from what very limited knowledge I have golang and rust have similar if not identical syntax and flow. Moving from one style to another is for sure a challenge but I think NOT adopting async await will be much more of a burden overtime.

[ilkescality]

I'd vote for it as well, I was also reading comment of @vrancurel here: https://github.com/scality/Vault/pull/1049 which makes a lot of sense. I think could be good to start adopting with new (-er) projects to start with.

[anurag4DSB]

I think the developer should be able choose to use callbacks vs async-await(syntactical sugar on promises).
There should be no constraint stating we cannot or can use aysnc await :)
Obviously, the reviewers can object against or for it.

Even all the examples in the latest MOOC courses use async await, and teach that way, so it will be kind of difficult for any new developer to switch back to callbacks and contribute.

[anurag4DSB]

Also, if we are comparing performance, we clearly know that native async/await is better than promises and async/await(babel) for our node version(v10)

What we might need to think about, is whats the performance differences between our current callbacks and native async/await :)

[rahulreddy]

I am not worried about micro benchmarking as it doesn't reflect real world usage, I think performance wise it's safe to say it's as good as callbacks.

[miniscruff]

I think the developer should be able choose to use callbacks vs async-await(syntactical sugar on promises).

I would argue swapping between the two would cause more issues than sticking to one when they are interchangeable. That is unless callbacks are the only way to do something I think going all async-await and getting familiar with the flow would work better than swapping around.

What we might need to think about, is whats the performance differences between our current callbacks and native async/await :)

I think it is also important to analyze newer versions that we have not yet adopted. Even if callbacks were better in node 10, they are on node 14 now and we may just want to upgrade. Half of the benefits @rahulreddy posted in the faster async link is only relevant in node 12, node 10 has too old of a v8 version.

I read the NPM release model here https://nodejs.org/en/about/releases/ so using node 10 makes sense but I do think upgrading to node 12 and once node 14 reaches "Active LTS" moving to that will make sense.

I am sure there is a reason why we are on Node 10 other 10 being a great number but I have not read or heard anything as to why.

[miniscruff]

PS. Node 14 has optional chaining which looks amazing btw. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Optional_chaining

[ilkescality]

oh wow, optional chaining looks pretty amazing indeed. would make lot of things so convenient.

[anurag4DSB]

I okay with node 12 as well, like we are doing in Utapi. But I don’t think it’s a good idea to use node 14 as of now(atleast for components which are a part of our enterprise solutions). As with every major version change we might introduce more bugs in S3C and may be zenko. And I am not sure if we want to be the first ones to identify bugs. Considering the complexity of our stacks (S3C And zenko). We might run into some bugs which don’t have a solution yet.

[miniscruff]

I okay with node 12 as well, like we are doing in Utapi. But I don’t think it’s a good idea to use node 14 as of now(atleast for components which are a part of our enterprise solutions). As with every major version change we might introduce more bugs in S3C and may be zenko. And I am not sure if we want to be the first ones to identify bugs. Considering the complexity of our stacks (S3C And zenko). We might run into some bugs which don’t have a solution yet.

Agree, given that Node has a calendar-based release model and predictable plans of support and adoption it would not be hard to create our own model that piggybacked on that for Node releases.

Consider an example for Node 14. For 6 months it is in "Current State" then it goes into "LTS Stable" at which point they consider it production-ready. We could at that point begin a slow adoption in our own predictable path. I would probably start with our internal dependencies and work our way up. Pausing on any external dependency that doesn't support the new release yet. Copy this model for all our languages and major dependencies, even OS's should have something. Looking at you centos and kubernetes.

[rahulreddy]

Re-reading these comments

I am sure there is a reason why we are on Node 10 other 10 being a great number but I have not read or heard anything as to why.

It's because we stick to LTS/maintenance and haven't upgraded yet as we were in the middle of releases and didn't have bandwidth, we should be very soon.

[rahulreddy]

So it's decided we are going to use async/await. I encourage using the pattern for any new code written. We will make the effort of modifying existing code as a tech debt for every release.