Async/await was introduced in NodeJS 7.6 and is currently supported in all modern browsers. I believe it has been the single greatest addition to J...
For further actions, you may consider blocking this person and/or reporting abuse
Important to mention that, although it looks cleaner, easier to read and everything, mainly for new developers, using
async/awaitmay trick you into not seeing points of opportunity for parallelism and you end up with a series of asynchronous call being treated as a plain synchronous code. For that cases where's there's in no need wait for things to be ran sequentially,Promise.allto the rescue!I don't really agree with this. You can make the same mistake with promises or async/await. You can still chain the promises instead of calling them in parallel
You surely can. My point here is not to confuse new devs making them think one replaces the other, because it doesn't. They are two tools you can combine to make the best out of your async flows.
Good post, by the way!
tbh I tend to get a little weird with parallel promises and combine destructuring,
await, andPromise.all():kinda gross, but personally I prefer it to returning to promise chains
Yeah, I do that myself (I don't think that's gross at all). That's the combination I think makes sense: we get the benefits of
async/awaitwithout giving up the parallelism.Debugging async/await is actually a total pain if you're working in a project that's using babel. If you're stepping through your code, the minute you hit an async call, you're thrown into polyfill. If you're aware of a workaround, I'd love to know about it!
Disable that in Babel and let it spit out the actual async/await code instead of polyfilling it. (I do that for various other features as well, HTML custom elements being a big one, since there isn't a good way to write those in an ES3 compatible manner; new.target and Reflect didn't become available until after classes, and since you need to call 'super()' or equivalent in the constructor...)
Combined with webpack or the like, I'm not sure there, I have yet to use it.
Not all browsers that I need to support can use async/await, unfortunately, so I need to let babel handle that still.
I get that entirely, but for the initial testing and debugging of such code, I'd still turn it off. It lets you get your logic in order without having to debug a polyfill at the same time.
Ah, I gotcha - just for the purpose of debugging. Makes sense!
Hi, this is probably a silly question, but how do you disable those generators in Babel? Thanks
That's interesting I don't think I had this problem. Do you have source maps enabled?
For context, this is in a Vue project (created with vue-cli 3), and it's in a local dev environment so source maps shouldn't matter I don't think? I'll have to do another test with this and see if it's still an issue.
Works fine in chrome dev tools.
I like a lot about await, but I don't like having to use try/catch - it's not a construct I'm used to...it forces me to use 'let' instead of 'const' if I want to have access outside the catch block. Also, it indents one more level. Perhaps I need to learn try/catch more, but I note your examples tend not to show error handling, except the one where it is claimed as an advantage.
I share your dislike of try/catch, but it's the only way to handle errors in synchronous code, so we don't really have a choice. Async/await enables us to use just 1 approach to handle both sync & async errors. I'd prefer to handle all errors in the same way, even if it's not my favorite way 🤷♀️
I also don't really like the aspect that it hides what is going on. It looks synchronous, but definitely isn't.
Then there's the kangaroo behaviour when stepping through it, which isn't expected from its "sequential" appearance.
Imo, it's trying to be "too clever".
... having said that, I still find myself using it.
Async/Await are promises! What your examples do not show is that your async/await functions actually do not return just string, but instead they return Promise, you can get away by returning just a string, because the compiler or interpreter wrapps them in a Promise, actually the whole async/await function gets converted to an promise based one.
I have been working on JS/TS past 2 years. Understanding Asynchronous JS, had become a challenge. This article has really given a good clarity on Async/Await.
Kudos! to you man.
I got your reference by Kait Hoehne, she has written an excellent article titled - Is JavaScript Synchronous or Asynchronous?:
betterprogramming.pub/is-javascrip...
I will be referencing your article, if I plan to write a blog on JS synchrounous & Asynchronous.
I wouldn't call it better because this code does 2 things that I try to avoid generally:
I try to make code easier to read and trace, even if it becomes a little more verbose
Good read. Didn't know about #7, thanks man!
I'm not entirely sure if this is still the case, but there are also performance reasons at stake related to stacktrace reconstruction to justify preference of async/await vs promises in V8.
Source: mathiasbynens.be/notes/async-stack...
Great read, thanks!
Just a small note - you're missing the word "Reasons" in the title :)
Oops. Fixed it. Thanks
Great post 😄
Nice work
Great Article @gafi .
I currently use Await/async on Dart; and I understand it better now.
Promises can really be a pain especially when they are nested.
YAY! JS needs this. Writing code this way is a lot easier... mind you, it's not perfect, but it's better than what we had before.