Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Your comment is a bit misleading, I doubt you looked for more than 30 seconds at that lib's documentation given the lack of detail in your response.

Just to be clear; I would never use that lib in any circumstance right now, I'd always prefer async/await for idiomatic reasons.

But please have a look at http://caolan.github.io/async/v3/docs.html#controlflow

Forever, queue, series, times, retry, until, waterfall, whilst, etc etc... these are patterns that can all be achieved with promises too but I am sure most devs will do a google search before they do. In fact; some patterns are better served by a library.

Only just yesterday I added https://www.npmjs.com/package/p-limit to get concurrent promise limitation behaviour; one of the many features of that async-lib as well.

Don't misinterpret this as me suggesting these features should be added to the standard; far from it. Community libs do this job quite well.

I moved on from async, I moved on from Promises and embraced async/await.

Do I like it? No, I much rather use Golang's channels. But async/await is idiomatic and plenty of libs out there to handle complex use cases.

Almost everyone has moved on, and anyone writing promises at this moment is just creating legacy for anyone who is going to maintain it. Is that a good reason in itself? No, but it is a very valid one, that is my point.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: