3 ms·

Kinf of OT, but can anyone share their experience about using Babel's async/await in production instead of regular Promises? I'd love to hear about people who

by ht85 10y ago

Kinf of OT, but can anyone share their experience about using Babel's async/await in production instead of regular Promises? I'd love to hear about people who have used it in large and complex projects, from a debugging standpoint. As of now, using Bluebird (with its source in a different, blackboxed script), it is possible to follow the code execution through the event loop with async debugging, in a very elegant and enjoyable fashion. I find async/await much more appealing when coding, but I'm worried about quality of life when hardcore debugging, as in my current project it can make me waste hours at a time when something if completely fringe happens.

jeswin 10y ago
I have some medium/large projects using async-await. There are 2 ways to transpile async-await. a) Default, with regenerator, transpiles it to ES5 b) If your env supports generators (like Node, or newer browsers), you can use async-to-generator plugin. Regenerator gives you unreadable code, but it will run everywhere. async-to-generator gives you (relatively) readable code. Source maps support has improved a lot, and you can choose to see only your original code while debugging. You'd be setting breakpoints on your code instead of transpiled code. So you should be fine whether you're using regenerator or async-to-generator. There might be corner cases (very rare) depending on your env; in which case if you're using regenerator you might need to switch to async-to-generator to find the bug. Source maps work well with node-inspector. If you'd like to see better stack traces in say "mocha" tests (or other test framework), use https://github.com/evanw/node-source-map-support https://github.com/evanw/node-source-map-support. Overall, the developer experience is now pretty good. Thanks to all the work that's gone into the tooling.
deleted 10y ago
[deleted]
ilaksh 10y ago
If you want a good solution to those types of problems in dynamic languages like ES6 then I think short functions and unit/functional tests are the best approach. Without that it is always going to be a bit challenging. Having said that I have not seen worse stack traces with 'async/await. I think they are similar.

by ht85 10y ago

jeswin 10y ago

I have some medium/large projects using async-await. There are 2 ways to transpile async-await. a) Default, with regenerator, transpiles it to ES5 b) If your env supports generators (like Node, or newer browsers), you can use async-to-generator plugin. Regenerator gives you unreadable code, but it will run everywhere. async-to-generator gives you (relatively) readable code. Source maps support has improved a lot, and you can choose to see only your original code while debugging. You'd be setting breakpoints on your code instead of transpiled code. So you should be fine whether you're using regenerator or async-to-generator. There might be corner cases (very rare) depending on your env; in which case if you're using regenerator you might need to switch to async-to-generator to find the bug. Source maps work well with node-inspector. If you'd like to see better stack traces in say "mocha" tests (or other test framework), use https://github.com/evanw/node-source-map-support https://github.com/evanw/node-source-map-support. Overall, the developer experience is now pretty good. Thanks to all the work that's gone into the tooling.

deleted 10y ago

[deleted]

ilaksh 10y ago

If you want a good solution to those types of problems in dynamic languages like ES6 then I think short functions and unit/functional tests are the best approach. Without that it is always going to be a bit challenging. Having said that I have not seen worse stack traces with 'async/await. I think they are similar.