3 ms·

What? Why? I disagree on all of those points. Promises are inconsistent[0], slow[1], and I find them a hassle compared to async. The Node.js core and community

by aroman 12y ago

What? Why? I disagree on all of those points. Promises are inconsistent[0], slow[1], and I find them a hassle compared to async. The Node.js core and community convention is to use callbacks and callback-embracing tooling for a good reason. [0] http://lostechies.com/derickbailey/2013/09/20/consistency-problems-with-apis-in-javascript-promise-libraries/ http://lostechies.com/derickbailey/2013/09/20/consistency-pr... [1] http://thanpol.as/javascript/promises-a-performance-hits-you-should-be-aware-of/#conclusions http://thanpol.as/javascript/promises-a-performance-hits-you...

notduncansmith 12y ago
Performance: I cannot honestly remember a single case in my entire Node.js career where promise execution time was a performance bottleneck. Inconsistency: If you're consistent in your promise library usage, then promises will always behave the same way. Wrap libraries as necessary. Promises are incredibly easy to reason about - the code reads very synchronously. Until we have native concurrency primitives available at the language level, I'll settle for ".then". It's pretty much how I'd read it in my head anyways. If promises are a hassle, you're probably not using them correctly.
danabramov 12y ago
Your assumptions are outdated and this is FUD. Promises that implement Promises A+ are consistent. The fact that jQuery's implementation is broken has no relation to promises whatsoever (nobody seriously calls them promises anymore). But I was talking about a different kind of consistency: consistency in your code. Errors not being swallowed, the same representation for all async values. The performance post you linked to is almost a year old and is quite outdated. Since it was posted, Bluebird[1] was written and leveled up the game: file time(ms) memory(MB) promises-bluebird-generator.js 171 16.52 callbacks-baseline.js 197 20.68 promises-bluebird.js 280 26.64 promises-lvivski-davy.js 616 58.75 promises-dfilatov-vow.js 672 80.59 promises-cujojs-when.js 731 68.74 callbacks-caolan-async-waterfall.js 733 44.57 [1]: https://github.com/petkaantonov/bluebird/blob/master/benchmark/stats/latest.md https://github.com/petkaantonov/bluebird/blob/master/benchma...

by aroman 12y ago

notduncansmith 12y ago

Performance: I cannot honestly remember a single case in my entire Node.js career where promise execution time was a performance bottleneck. Inconsistency: If you're consistent in your promise library usage, then promises will always behave the same way. Wrap libraries as necessary. Promises are incredibly easy to reason about - the code reads very synchronously. Until we have native concurrency primitives available at the language level, I'll settle for ".then". It's pretty much how I'd read it in my head anyways. If promises are a hassle, you're probably not using them correctly.

danabramov 12y ago

Your assumptions are outdated and this is FUD. Promises that implement Promises A+ are consistent. The fact that jQuery's implementation is broken has no relation to promises whatsoever (nobody seriously calls them promises anymore). But I was talking about a different kind of consistency: consistency in your code. Errors not being swallowed, the same representation for all async values. The performance post you linked to is almost a year old and is quite outdated. Since it was posted, Bluebird[1] was written and leveled up the game: file time(ms) memory(MB) promises-bluebird-generator.js 171 16.52 callbacks-baseline.js 197 20.68 promises-bluebird.js 280 26.64 promises-lvivski-davy.js 616 58.75 promises-dfilatov-vow.js 672 80.59 promises-cujojs-when.js 731 68.74 callbacks-caolan-async-waterfall.js 733 44.57 [1]: https://github.com/petkaantonov/bluebird/blob/master/benchmark/stats/latest.md https://github.com/petkaantonov/bluebird/blob/master/benchma...