DEV Community

Discussion on: 7 Reasons Why JavaScript Async/Await Is Better Than Plain Promises (Tutorial)

Collapse
 
ffxsam profile image
Sam Hulick • Edited

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!

Collapse
 
gafi profile image
Mostafa Gaafar

That's interesting I don't think I had this problem. Do you have source maps enabled?

Collapse
 
ffxsam profile image
Sam Hulick

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.

Collapse
 
ironydelerium profile image
ironydelerium

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.

Collapse
 
ffxsam profile image
Sam Hulick

Not all browsers that I need to support can use async/await, unfortunately, so I need to let babel handle that still.

Thread Thread
 
ironydelerium profile image
ironydelerium

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.

Thread Thread
 
ffxsam profile image
Sam Hulick

Ah, I gotcha - just for the purpose of debugging. Makes sense!

Collapse
 
termita81 profile image
RP

Hi, this is probably a silly question, but how do you disable those generators in Babel? Thanks